Service ownership and routing
Service ownership and routing
Service ownership and routing How a LaunchPad-deployed service model exposes ownership data, and how Jira Service Management can put that data to work.
Every service model LaunchPad installs includes owner fields on its service-level object types. Routing is the most common use, and this page covers it in detail. But the same ownership data feeds reporting, dashboards, Assets queries, virtual service teams, escalation models, and request field mapping. Once the data is in place, you decide how much of it to draw on.
Ownership fields in a deployed service model
Every service in a LaunchPad-deployed service model has an owner field. The field accepts a specific team or person reference. Automation rules that read the owner resolve an assignee from that value. Fields left unpopulated, or populated with generic values (for example "IT"), will not resolve to a specific queue.
LaunchPad installs the ownership structure, and it can also expand existing service models and ownership structures over time. Deployment puts the model in place; populating the fields for your actual services is the next step. As your environment grows, LaunchPad's create-only merge engine adds new service types and reference types into a deployed service model without modifying or removing what is already there, so the ownership model keeps pace with the services you run.
What routing resolves to
When a ticket in Jira Service Management is linked to a service object, the ticket carries a reference to that object. An automation rule reading the service field can resolve the owner via the reference and assign the ticket accordingly.
Without the link, the ticket carries no structural reference and cannot be routed by service.
Concrete example: Customer Portal
An incident is raised. The ticket is linked to the Customer Portal service object.
- Customer Portal is a service object in the deployed service model.
- Its owner field references the Digital Platform team.
- Its reference types connect it to Authentication Service and Hosting Infrastructure.
An automation rule reads the service owner and assigns the ticket to the Digital Platform team. The dependency references surface the wider context inside the Assets graph view.
Beyond routing: other uses of ownership data
Once owner fields are populated, the same structured data is available to more than automation. You can:
- Report on ownership. Group incidents, requests, and changes by owning team to see where load sits and which services drive volume.
- Build dashboards. Surface per-team or per-service views so each owner can track their own queue and trends.
- Query in Assets. Filter and search service objects by owner, dependency, or category directly in the Assets view, with no ticket required.
- Define virtual service teams. Use owner references to group services that are run by the same people even when they sit across different categories.
- Drive escalation models. Read the secondary-owner reference (see below) to send breaches and high-priority work to the right escalation contact.
- Map request fields. Connect a request type's fields to the service objects and owners behind them, so the right ownership data is captured at intake.
For that last point, LaunchPad's Request Flow Analysis audits the fields, screens, and request types in a project and surfaces enrichment opportunities and duplicates, which helps you decide where ownership data should feed your request forms. To see how the service model fits your current setup before you wire any of this up, run Environment Analysis (also shown as "Scan your environment") to review what is already in your environment.
Wiring a deployed service model into Jira Service Management
LaunchPad provides the service model structure. The Jira Service Management configuration that consumes it is done on your side. Typical configurations:
Route by service field. A service field is added to a work type. An automation rule reads the service, looks up the owner, and assigns the ticket.
Route by category. When individual services are not linked on every ticket, routing falls back to a service category or functional area referenced by the service model.
Escalation paths. A secondary-owner reference on the service object provides an escalation target. A rule firing on threshold breach reads the secondary owner and reassigns.
What LaunchPad does and does not do
| LaunchPad provides | Configured in Jira Service Management |
|---|---|
| Service objects with owner fields | Service field on Jira work types |
| Ownership attributes on every service | Automation rules linking service to assignment |
| Reference types between services and teams | Escalation policies, SLA policies |
The service model is the data model. The automation that consumes it is configured in Jira.