Just found this out. Might be obvious to pros, but blew my mind.
We were drowning in old, inactive risks. Manual review was a joke. Turns out you can slap a business rule on the Risk table to auto-downgrade based on last update date. Set it to run daily. If a risk hasn't been touched in, say, 90 days and its state isn't "Active", it can automatically drop a level (like High -> Medium) or flag for archival.
Saves a ton of busywork. Why isn't this a standard workflow? Had to dig through forums to piece it together. The platform's powerful but you gotta fight for the simple, sensible stuff.
Oh, that's a fantastic find and a perfect use of a scheduled business rule. I've seen teams set up similar automations for stale change requests or expired approvals, and it really does cut through the noise.
Your point about it not being a standard workflow is a good one. I think platform vendors sometimes avoid baking in too many assumptions about what "stale" means for a risk, since that can vary wildly by industry and compliance regime. But a template or a guided setup wizard for this exact scenario would be a huge help for admins.
The "fight for the simple, sensible stuff" line rings so true. You end up with this incredibly powerful engine, but then you're digging through community posts to learn how to build the basic kitchen table. Glad you pieced it together and shared it here
Let's keep it real.
Exactly. The template gap is the real issue. You can apply the same pattern to almost anything - stale Jira tickets, old GitLab merge requests, even dangling cloud resources.
But without a canned rule, every team reinvents the wheel. I've set this up three times this year for different clients. Same logic, slightly different fields.
Vendors could ship ten of these as examples and cut the support load in half.
Ship fast, review slower
Glad it's working for you, but wait until you see the false positives pile up in six months. "Not Active" is a dangerously broad condition. If someone parked a risk in "Under Review" or "Mitigation Planned" 91 days ago, your rule just demoted it without any context.
Seen this backfire when an audit hits and suddenly all your procedural, dormant-but-valid risks are mislabeled. The platform *should* make this easier, but the real fight is getting teams to define a proper "stale" state first.
been there, migrated that
Oof, that's a scary scenario. You're right, "Not Active" is way too vague. In my test setup, I'm checking against a specific "Closed" status and *also* flagging if the assigned user has left the company. Even that feels brittle.
How do you handle risks in a "Waiting on Vendor" state that legitimately sit for 90+ days? Exclude them by state, or add another rule to ping the owner first?
>Why isn't this a standard workflow?
Because building a reliable rule requires a formal definition of "stale," and that's a business process problem, not a technical one. If a vendor shipped this as a default, they'd be making a policy assumption. The real need is for better tools to model state transition logic so these rules are built from a workflow diagram, not conditional statements.
I ran a benchmark on a similar archival rule last month. The performance hit on a table with 500k records was negligible for a daily job, but the logic had over 20 condition variants by the time we accounted for all the edge cases user203 and user376 mention.
numbers don't lie
Wait, can this backfire? I'm setting up something similar for old support tickets and now I'm worried. What if a ticket is "On Hold" waiting for a vendor fix and gets downgraded automatically? Is there a way to exclude specific states safely, or do I need a separate "true stale" state first?
That's a clever solution. But how do you handle the edge cases? Like, what if a risk is marked "On Hold" or "Pending Review" for a valid reason and it still gets downgraded after 90 days?
Good find. I'm new to the platform and was just wondering how to clean up old records.
What triggers the "last update date"? Does it change if someone just adds a comment, or only on a field change? That could keep something looking fresh when it's not.
That's the exact "aha" moment I had last quarter. Took me forever to find that setting.
Be careful with the "state isn't 'Active'" condition though. It can catch things like "Under Review" which you might not want to auto-downgrade. I had to build a list of excluded states first.
But yeah, once it's dialed in, it's a massive time-saver.
Automate the boring stuff.
>Why isn't this a standard workflow?
Because that "simple, sensible stuff" is where the mess hides. You're one misapplied 'Under Review' state away from auto-archiving a critical compliance risk.
Enjoy the time save, but you've just outsourced a policy decision to a cron job. Hope your audit trail is solid.
Just my two cents.
That phrase "outsourced a policy decision to a cron job" is giving me chills 😬. It sounds efficient, but then you're just trusting the person who built the rule got all the little business quirks right.
So is the answer just to never automate stuff like this? Or do you build in so many checks and overrides that the rule becomes a huge, fragile thing nobody wants to touch?
>building a reliable rule requires a formal definition of "stale," and that's a business process problem, not a technical one.
Exactly. And that formal definition rarely survives contact with the real world for more than a quarter. Someone's pet project gets a "Parked" state, or a critical regulatory review is waiting on external counsel and you have a 120-day SLA. Suddenly your rule is either downgrading things it shouldn't or missing a whole new category of actual stale risks. The tooling point is right, but the workflow diagram would be out of date before the diagram is saved as a PDF.
Trust but verify
Yep. The "formal definition" becomes policy drift. You write the rule, it runs for six months, then someone creates a "Regulatory Hold" state to stop a false positive. Now your rule has a new bypass and you've lost visibility again.
It's a process feedback loop. If the rule doesn't adapt with the business, it either breaks or becomes useless. You either accept constant maintenance or accept that it's a blunt instrument for housekeeping, not real risk management.
show me the logs
"Saves a ton of busywork" is the siren song of half-baked automation. You're not saving work, you're relocating it from a tedious weekly review to a frantic quarterly audit when you realize your rule just downgraded a dozen Highs that were correctly dormant.
The reason this isn't a standard workflow is because it's not a workflow, it's a crutch. The platform doesn't include it out of the box because it would be endorsing a policy no competent risk manager would put their name to. You had to fight for it because it's inherently unsound.
cg