After installation: what happens
After installation: what happens
After Installation: What Happens What LaunchPad has built in your environment, and the three things worth doing before anything else.
The installation is done. So what is actually in your environment now, and what does it mean for how your team works?
This page answers both of those questions.
What LaunchPad just built
Depending on the model you installed, your Assets environment now contains a structured schema with some combination of:
-
Service objects: the services your team manages and supports
-
Application objects: the applications that underpin those services
-
Infrastructure objects: the systems those applications run on
-
Vendor objects: third parties providing components or services
-
Relationships connecting all of the above in a way that reflects how they actually depend on each other
-
Ownership fields that allow you to assign accountability across your service estate
None of this is placeholder content. It is a working structure, built to reflect how real service environments operate. What you are looking at is the kind of schema that normally takes a consultant engagement to design and configure, already in place, already connected.
Go and look at it
Before doing anything else, open it.
Jira → Assets → Object schemas
You will see your new schema listed. Open it. Click through the object types. Follow some relationships. Get a feel for the shape of what is there.
This matters because the next few steps, assigning ownership, connecting your request types, validating with real scenarios, all make more sense once you have seen the structure firsthand.
If you can see connected objects with relationships between them, installation has succeeded.
What is now possible
With the schema in place, your Jira Service Management environment can now support:
Service ownership: every service has a home. You can assign owners, define accountability, and use that structure for routing and escalation.
Impact analysis: when something breaks, you can follow relationships from the affected CI to understand what is impacted upstream and downstream. No more guessing.
Change risk awareness: before making a change, you can see what depends on the component you are touching. The information exists; now it is structured.
Routing and reporting: with ownership and relationships defined, you have the foundation to route requests intelligently and report against your service estate.
What is not automatic
LaunchPad builds the structure. It does not connect your existing tickets to it, populate historical data, or modify your existing workflows. Those steps involve your team's decisions about how to work, and they are covered in the sections that follow.
Think of what you have now as a well-designed empty building. The rooms are laid out properly, the wiring is in, the labels are on the doors. Your team decides how to move in.
Three things worth doing before anything else
1. Assign ownership to key services. Open your most critical services and put an owner against them. This is the single action that makes the most other things possible: routing, escalation, accountability.
2. Review a few relationships. Pick a service and trace its dependencies. What does it depend on? What depends on it? If that picture makes sense for your environment, you are in good shape. If something looks off, it is worth adjusting now before you build on top of it.
3. Test with a real scenario. Raise an actual incident or request, identify the affected service in Assets, and check whether ownership and relationships give you useful information. If they do, your model is operational.