How it works
How it works
From install to a working service model in a few minutes. No configuration files, no lengthy setup. This page walks through the deployment flow and explains what happens technically at each stage.
The three-step deployment flow
Step 1: choose a service model
Open LaunchPad from within your Jira Cloud site. The gallery presents the available service models organised by category. If you have run Scan your environment, LaunchPad also recommends the models that best fit what it found.
Each card shows the service model name and description, the number of object types and attributes, and its complexity level (Starter or Operational for the current catalogue). Click on any service model to open a detailed preview showing every object type, its attributes, and how types relate to one another.
Step 2: configure
Once you have chosen a service model, you provide a name for the deployment. For a model that references Core, you also choose, per reference, whether each spoke links to an existing Core schema, creates the referenced type locally, or keeps it as plain text. The service model defines everything else.
Step 3: review and deploy
LaunchPad shows a pre-deployment preview of exactly what it will create. You review it before anything is built. When you confirm, LaunchPad creates the complete service model in your Assets workspace and you can watch the progress in real time. Once deployment completes, the app shows a success confirmation with a direct link to your new schema.
What happens technically
When you click deploy, LaunchPad performs a precise sequence of API operations against the Assets REST API. If you are curious about the internals, here is the breakdown.
1. Schema creation
The app creates a new object schema in your workspace. This is an empty container that does not affect any existing schemas.
2. Object type creation
Each object type is created within the new schema. The app respects parent-child hierarchy, ensuring child types are created after parents.
3. Attribute creation
For every object type, each attribute is created with the correct configuration:
| Attribute type | Handling |
|---|---|
| Text, integer, float, boolean, date, email, URL | Created with their specified types |
| Select | Created with pre-defined option values |
| Object reference | Created last, after all object types exist |
4. Reference type resolution
The app checks which reference types already exist in your workspace and reuses them rather than creating duplicates. If a service model requires a custom reference type that does not already exist, the app creates it inline through Forge, with no API token or extra credentials to configure. For references that point at Core, the mode you chose at configure time decides whether the reference links to an existing schema, creates the target type locally, or is kept as text.
5. Icon assignment
Each object type is assigned an appropriate icon, matched by name against the Assets built-in icon library.
Batched processing for large service models
Atlassian Forge functions have a 25-second execution timeout. LaunchPad handles this automatically through batched processing:
| Mechanism | Detail |
|---|---|
| Batch size | Up to 10 operations per invocation |
| State persistence | State persisted between batches |
| Frontend polling | Triggers next batch until complete |
| Progress indicator | Shows deployment progress in real time |
From your perspective, you click deploy and watch the progress bar. The batching is entirely transparent.
Safety guarantees
Every deployment follows strict safety rules:
| Guarantee | Detail |
|---|---|
| Additive only | Only creates new schemas, object types, and attributes. Never modifies or deletes existing data. |
| Isolated schemas | Each deployment creates a self-contained schema. |
| Idempotent naming | Alerts you if a schema with your chosen name already exists. |
| No third-party servers | Runs entirely on Atlassian Forge. No data is sent outside the Atlassian platform. |
Safe to try on production. LaunchPad never touches your existing schemas or data. If you deploy something and change your mind, just delete the new schema from Assets. Everything else stays exactly as it was.
After deployment
Once your service model is deployed, it is fully yours. LaunchPad does not lock you in. Your options:
-
Add data manually; open any object type and start creating records
-
Import via CSV; use Assets' built-in CSV import to bulk-load data
-
Connect discovery tools; point asset discovery tools at your new schema
-
Extend the model; object types and reference types stay editable after deployment, and Expand a Service Model adds new types and references through the create-only Merge engine without touching what is already there