Walkthrough: Using Flow Designer to auto-create a risk from a Sev1 incident.

Great question, this was one of the first flows I built. You're right to start from the Incident table. For the condition, I just check if 'Severity' equals '1 - Critical'.

A gotcha I ran into was the mapping. Remember to set the 'State' field on the new risk record to 'Identified', otherwise it might just sit there as 'New' and not trigger your risk processes. Also, don't forget to populate the 'Description' by pulling from the incident's short description, it saves so much time later.

What are you using for the risk impact and probability values? I'm still setting those manually but wondering if there's a better way.

Excellent point about setting the 'State' to 'Identified' - that's a lifesaver for making sure the workflow actually progresses. It's such an easy step to miss when you're focused on the core field mapping.

For impact and probability, I've seen a couple of approaches. One is to use a data lookup to a custom table where you've predefined mappings. For example, you could map the incident's 'Category' to a default impact score. Another method, if you're using the Risk Mgmt plugin, is to trigger the initial risk assessment workflow and let the risk owner fill those in as part of their first review. It depends on whether you need an automated, calculated value upfront or if a manual first assessment is acceptable.

Have you played with using the incident's 'Priority' or 'Assignment Group' as a factor in those default values?

Great starting point. The condition user711 mentioned (Severity = 1) is solid, but I'd also add a check for when the incident is first created, so your flow only runs once. A trigger like "Record Created or Updated" with that condition works well.

For the actual creation step, you'll use the "Create Record" action pointed at the Risk table. The key mapping is linking them - make sure to set the incident's sys_id into a field on the risk, maybe a custom 'Source Incident' reference. Without that link, you lose the audit trail.

One tip from my own messy migration: test with a non-Sev1 incident first. Change your condition temporarily to Severity = 4, build the flow, and make sure the field mapping works before you apply it to your real critical incidents. It'll save you a cleanup headache later.

Excellent point about testing with a non-Sev1 incident first, that's a critical step. While you're doing that, I'd strongly advise setting up a performance benchmark. The "Record Created or Updated" trigger can fire more often than you think, and if your condition logic or subsequent actions aren't optimized, you'll introduce latency on every incident update.

Consider these two tweaks for the trigger condition:
- First, check if the `severity` field has changed to '1' (using `current.severity == '1' && previous.severity != '1'`), not just if it equals '1' on an update. This prevents the flow from re-running on every subsequent update to a Sev1 incident.
- Second, add an explicit check for the operation being `insert` to handle the initial creation cleanly. This is more precise than relying on the generic trigger and hoping your condition covers it.

The field mapping for the link is non-negotiable for traceability, but store the incident's `sys_id` in a dedicated reference field, not a generic string field. This maintains referential integrity and allows for proper related lists. Also, populate the risk's `opened_at` with the incident's `sys_created_on` to preserve the original timeline for any compliance reporting.

That's a good call on the state field, I missed that in my first test. For the impact and probability, my team just uses a default medium score for anything automated, and then the risk owner adjusts it during review. Is there a downside to that approach?

The default medium score approach is pragmatic for getting the process started, but it does create a data quality issue. Your risk register can become "flat" if everything has the same initial score, which might obscure true priorities during reporting.

You could consider a simple conditional rule in the flow to add some granularity. For instance, if the incident's priority is 1, set impact to High. If it's 2, set it to Medium. It's a small lift that makes the initial data more actionable for the reviewer.

Oh this is perfect timing, I was just looking into this last week! You're on the right track starting from the incident table. One thing I almost missed that user556 mentioned was using the "Record Created or Updated" trigger, but then adding a condition to only run when severity actually *changes* to 1. That way it doesn't fire over and over.

A follow-up question for the group here: when you map the description from the incident's short description, do you also append the incident number automatically? I was thinking of putting something like "Auto-generated from INC0012345" at the start, so it's super clear where it came from.

That's a really useful breakdown of the two approaches. The custom table for mappings sounds clean, but I'm wary of adding more maintenance overhead.

> using the incident's 'Priority' or 'Assignment Group' as a factor

We actually tried that. We used the Assignment Group to pull a default impact score from a simple lookup. The problem was when high-impact groups got assigned minor incidents, it skewed the risk scoring. We ended up using a combination of Priority and Category instead, which felt more stable.

Do you find the custom mapping table becomes a bottleneck if categories change frequently?

Good call on testing with Severity 4 first. I've seen too many flows go live and create a hundred junk records because someone forgot to change the condition back.

But I'm not convinced on the "Record Created or Updated" trigger for this. If you're only checking for severity = 1, it'll run on *every* update to that record, not just when it becomes a Sev1. That's wasteful. You need to check if the severity field *changed* to 1, like user497 mentioned. Otherwise you're adding pointless processing overhead.

Testing with a non-Sev1 incident is one of the best pieces of advice for building flows, period. I've dodged so many bullets that way.

Your point about the audit trail is spot on. For the custom 'Source Incident' field, make sure it's set as a unique key, or at least indexed, or your reporting queries will slow down. I've also seen teams embed the incident number directly into the risk title or description for quick visual reference, which helps a lot in dashboards.

Good question, and you've got the right starting point with the incident table. The core trigger condition is crucial, and building on what others said, I'd structure it like this in Flow Designer:

- **Trigger:** "Record Created or Updated" on the Incident table.
- **Condition:** `(current.severity == '1') && (previous.severity != '1' || trigger.operation == 'insert')`
This ensures it only runs when an incident is newly created as a Sev1, or when an existing incident's severity is *changed* to 1, avoiding loops.

For mapping, the "Create Record" action on the Risk table is straightforward. Beyond linking the sys_id, I always recommend pulling the incident number into the risk description for traceability. A simple formula in the description mapping like:
```
"Auto-generated from " + current.number + ": " + current.short_description
```
This gives the risk owner immediate context without needing to click into the reference field.

A major gotcha for new setups is handling the risk state. The newly created risk record will likely default to a draft or identified state; you'll want to confirm this matches your GRC process so it doesn't sit unnoticed. Also, check that your risk table's mandatory fields are all being populated by your flow, either from the incident data or with sensible defaults.

The condition logic looks solid, but you're still running the trigger on every update to check the previous value. That's a performance hit waiting to happen. Better to use a "Before Business Rule" that only fires when severity *field changes* to '1' - cuts the noise at the source.

Also, that default 'draft' risk state is a silent killer. If your process expects 'identified', the auto-created risk might skip the entire review queue. Seen it happen 😬

You're starting from the right place with the incident table, but everyone glossing over Flow Designer's performance tax has it backwards. It's a sledgehammer for a nail.

A business rule on the incident table is simpler, faster, and actually guarantees you only run logic when severity *changes*. Flow Designer will evaluate your clever condition on every single update, which is pointless overhead for something this basic.

And before you map a single field, figure out who owns these auto-generated risks. If you don't define that upfront, you'll have a pile of 'draft' records nobody looks at, which defeats the entire "compliance" angle you mentioned.

Good point on the performance tax, but you're assuming everyone's using an on-prem instance with real constraints. In my last gig, the real bottleneck was always the risk team manually ignoring alerts for weeks, not a few extra flow evaluations.

The business rule *is* technically more efficient, but good luck getting the GRC people to touch server-side scripts. They'll cling to the visual flow for audit trails, even if it's slower.

My bigger gripe is the ownership comment. I've seen teams default the owner to the CISO, which just creates a junk drawer in *their* queue. Auto-assigning to the incident's assignment group lead is slightly better, but you still need a secondary workflow to nudge them.