Modeling Assets in Jira Service Management: decisions first, schema second

The most common mistake: process before model

Design the process before the model and you get a service desk that records work very well and reduces none of it. Three signs give it away:

• The form does the thinking. Portal fields ask the reporter for things the tool should already know: which system, which site, how urgent. The reporter guesses, and the guess becomes your data.

• Automation gets hardcoded. With no model to read, a rule has to name things: if the service is payroll, assign to team A. Fifty services become fifty rules, and every new service is a change request against your own tooling.

• The agent is the missing link. Someone reads the ticket, works out the system, remembers the team that owns it, sets a priority and reassigns. Dozens of times a day, from a table that exists only in their head.

None of this is a config error. It is what happens when you design behavior before the structure that behavior requires. And if you add Assets later, you pay twice: forms shrink, rules are discarded, workflows and SLAs are re-cut, all on a running service desk.

Four decisions, not four hundred requirements

Model first does not mean modeling blind. It means starting with the decisions the tool should make on its own:

• Who gets this ticket?

• Which SLA applies?

• Who approves?

• What breaks if this changes?

Each one needs a small, specific set of fields and relations. Model exactly those. Modeling for four decisions takes weeks. Modeling everything you own is a project that never ends.

Four steps to a model that decides

1. Collect the decisions, not the requirements. What must the tool decide on its own?

2. Model what those decisions need. For routing, for example: affected service, owning support group, criticality, service tier.

3. Design the processes on the model. The request type fills its own fields from Assets, and the workflow uses what the object already knows.

4. Write generic rules. Instead of "if service is payroll, assign to team A with high priority", the rule reads the object: send it to the support group linked to the affected service, take the priority from criticality, take the SLA from service tier, notify the owner when the object is business-critical.

The same principle carries further: SLA goals come from object attributes, so a production system and a test system never share the same clock. Escalation and approval follow the roles stored on the object. And with AQL, the portal only offers reporters the objects they actually have.

Example: request routing before and after

Process first: A user reports an outage into a central queue. An agent reads it, works out the system, remembers the team, sets a priority, reassigns and escalates by hand. A new service means a new rule.

Model first: The user picks the affected service from Assets. One rule reads the object and does the rest. No triage, no reassignment, no rule written for this service. A new service means a new object.

That is where the scalability comes from. When a new service goes live, someone creates the object and links it to the owning team with its criticality and tier. From the next ticket onward, the routing is correct, and nobody touched a rule. A reorganization works the same way: change the relation on the objects a team owns, and every affected service reroutes at once.

Do the math with your own numbers

Your rule count: Count the automation rules that name a specific service, team, site or system in their conditions. Then count your services. If both numbers grow together, your logic is hardcoded. With a model, only the number of services grows: one rule covers ten services or four hundred.

Your triage time: Multiply the tickets per day by the seconds an agent spends working out the system, the owner and the priority before real work starts. As an illustration: 300 tickets a day at 90 seconds each is 7.5 hours a day, more than one full-time role spent on a lookup the model could do instantly.

Already live? Start here

Almost nobody starts from scratch. You do not have to start again, and you should not model the whole estate before you see a result.

• Pick one decision, not one schema. Routing is the usual first choice: the effect is visible within a week, and the data it needs is small.

• Run it beside the old logic. Pilot on one service group with the generic rule live and the hardcoded rules still in place as a fallback. Compare, then retire the old rules for that group.

• Report the rules you remove. "Rules removed" is the clearest proof that the model is doing the work.

• Reuse the model for the next decision. SLA, approvals and change impact largely read the objects you have just modeled, so the second decision costs a fraction of the first.

Then give the model an owner. Every object type needs a named owner, a source of truth, a lifecycle from purchase to disposal and a review date. Data quality is not a phase; it is a job.

Five questions: does your model decide or just describe?

1. Can a rule find the right assignment group from the affected service without naming that service in the rule?

2. Does your SLA come from the object or from what the reporter picked?

3. When you add a new service, are you changing data or changing a rule?

4. Does every object type have a named owner and a source of truth?

5. When did an object last change state without a human editing it by hand?

Three or more shaky answers mean your model describes but does not decide.

The Asset Scheme Blueprint

Our Asset Scheme Blueprint is a documented JSM use case library for routing, SLA, approvals and change, built from real projects. You adapt a model that works instead of designing a CMDB from scratch. The whitepaper and blueprint are free.

Why a service desk also has to be thought of as an operating model is the subject of Jira Service Management as an operating model .