Priority Matrix

[LiamO]

Hello! 

We currently have two record producers, one for general incidents and the other for specific security incidents (only using ITSM module).

A requirement is to have a separate Priority Matrix for incidents logged under the security incident record producer. 

Would this possible and if so, what would be the best practice to achieve this? 

Thanks in advance, 

Liam

[fknell]

Hi @LiamO ,

Yes, this is possible, and the cleanest way is to decouple the “security incident” priority logic from the standard ITSM priority matrix rather than trying to maintain two separate OOB matrices.

I would recommend one of these patterns, depending on how strict the requirement is:

1. Use a custom priority field for security incidents

- Add a custom priority field (e.g., u_security_priority) on the Incident table and expose it only in the security‑incident record producer.

- Keep the standard priority field driven by the OOB Impact/Urgency matrix for general incidents.

- For security incidents, either:

   - Let the record producer script set u_security_priority based on a custom lookup table, or

   - Use a business rule on incident that maps u_security_priority to the standard priority if you still need SLA‑driven behavior.

2. Drive priority from a custom matrix in the record producer

- If you must use the standard priority field for security incidents, I would suggest:

- Hiding impact and urgency from the security‑incident record producer and instead exposing a custom “severity” variable.

- In the record producer script, set impact and urgency based on that severity so the OOB priority matrix still works, but with values tailored to security‑incident logic.

3. Avoid multiple OOB priority matrices

The base priority matrix is not record‑producer‑aware, so you cannot natively have two different matrices for the same table; instead, use custom fields or scripts to keep the logic separated.

Another alternative would be creating a scoped app for the sec incident, which also let you manage access to security incidents separate from normal incidents and you could adjust the process flow too.

Hope this helps...

[Itallo Brandão]

Hi @LiamO ,

Yes, and please avoid scripting this (Business Rules/Client Scripts). You will end up fighting the native priority calculation engine on every update.

The Best Practice: Use a separate Data Lookup Definition with a specific Condition.

1. Create a custom matcher table (e.g., u_security_priority_lookup) to hold your specific matrix rows.

2. Create a new Data Lookup Definition pointing to that table.

3. Add the Condition: Category IS Security (or however you identify the record producer).

This effectively "forks" the logic: Security incidents get your custom matrix, and everything else falls through to the standard global rules without any conflict.

If this helps, please mark it as Accepted Solution.

Best regards,
Brandão.

[LiamO]

Thanks for the info! 

Would you have any further info for your point 3? Have not been able to find how to achieve this point...  

[lauri457]

Not sure if it even works to have two priority matrixes for the same table unless you edit the original lookups to have the inverse of condition in point 3. I'd expect the execution order to be sporadic at least if you have matches from two tables but not sure. You might as well edit the oob one to simplify the config.

1. Add a field that matches the SIR differentiator in [incident] in [dl_u_priority]

   I added a tickbox, yours might be something else

2. Go to the data lookup definition [dl_definition] for incident and add the matcher field definition from point 1 
3. Add the priority combinations in [dl_u_priority] for your security incidents