Assets, fields and factors
These three cause more confusion than anything else in the app, because in a demo they look like one feature. They are not. Each owns a different question.
| Concept | Owns the question | Example |
|---|---|---|
| Custom asset list | What is true about each thing? | Core Banking is Tier 1, not internet-facing, owned by Irakli |
| Custom field | Which values may I pick? | Affected application — any active application |
| Factor | How does an answer become a number? | Tier 1 scores 5, Tier 2 scores 3, Tier 3 scores 1 |
How they chain together
Configured together, they let the app score part of a risk for you. The full setup is on Custom assets, Custom fields and Factors in the Configuration section; here is the shape of it:
- An asset list called Applications holds a record per application, each with a
criticalityattribute. - A field called Affected application takes its options from that list.
- A factor called Asset criticality reads the
criticalityattribute of whichever application was chosen, and maps it to a score. - A methodology gives that factor a weight inside the Impact dimension.
- A layout puts the field on the identification stage, before assessment.
The result: a risk manager picks Core Banking in step 1 of the Add Risk wizard, and in step 2 the impact score is already partly filled in — because the app knows Core Banking is Tier 1.
Why this is worth the setup. Re-tier an application once, in one place, and every risk raised against it from then on scores differently. The alternative is asking every risk manager to remember which systems are critical, and hoping they agree.
Jira Assets as an alternative source
If you run Jira Service Management Premium, a field can take its options from a JSM object schema instead of a custom asset list, and a factor can read an attribute from it in the same way. The chain is identical.
Custom asset lists exist because JSM Premium is a significant additional cost, and asset-driven risk should not depend on it.