- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Community,
We understand that native Risk Event Management requires IRM Enterprise.
Before recommending an upgrade, we are clarifying the customer’s requirements and exploring whether a simpler process can be supported using existing IRM Professional capabilities.
Has anyone used Issue Management or another Professional capability to capture operational occurrences, record their impact, link them to risks/entities, and track corrective actions?
We would appreciate practical guidance on:
What can be achieved through standard configuration?
What gaps would require custom fields, flows, scripts or tables?
What are the maintenance and upgrade implications?
Which requirements would make native Enterprise Risk Event Management necessary?
We are looking for an approach within Professional’s entitlements, without enabling Enterprise-only functionality. Examples and lessons from actual implementations would be helpful.
Thank you.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi,
Issue Management could be a practical starting point if the main requirement is to record operational issues, link them to risks, assign owners, and track corrective actions.
However, it should not be treated as a direct replacement for Risk Event Management. OOTB Risk Event Management supports a dedicated lifecycle for event validation, impact/loss recording, root-cause analysis, risk association, approvals, and remedial actions.
With IRM Professional, you can evaluate whether the standard Issue Management process meets the requirements. If you need to capture additional event details, you may need custom fields, relationships, and workflow automation. Customization would also mean owning the ongoing maintenance and regression testing.
I would recommend mapping each business requirement against the capabilities available in your licensed version before deciding whether customization is sufficient or native Risk Event Management is necessary.
FYR:
Helpful? Please mark the response as Accepted Solution ✅ and close the thread 🔒 — this helps future readers find the solution faster.
Regards,
Sachinvic
✨ ArchX Certified | ✨ 16x ServiceNow AI MVP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi,
Issue Management could be a practical starting point if the main requirement is to record operational issues, link them to risks, assign owners, and track corrective actions.
However, it should not be treated as a direct replacement for Risk Event Management. OOTB Risk Event Management supports a dedicated lifecycle for event validation, impact/loss recording, root-cause analysis, risk association, approvals, and remedial actions.
With IRM Professional, you can evaluate whether the standard Issue Management process meets the requirements. If you need to capture additional event details, you may need custom fields, relationships, and workflow automation. Customization would also mean owning the ongoing maintenance and regression testing.
I would recommend mapping each business requirement against the capabilities available in your licensed version before deciding whether customization is sufficient or native Risk Event Management is necessary.
FYR:
Helpful? Please mark the response as Accepted Solution ✅ and close the thread 🔒 — this helps future readers find the solution faster.
Regards,
Sachinvic
✨ ArchX Certified | ✨ 16x ServiceNow AI MVP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello
Thank you, this distinction is helpful.
To clarify our scenario: a vendor fails a contractual obligation, such as a missed SLA or data loss. The customer wants to manage the resulting TPRM issue and corrective actions, while also tracking the occurrence, impact and associated risks centrally in IRM. They call this an operational “incident,” rather than an ITSM incident.
Based on your implementation experience:
Can the TPRM issue remain the primary record and provide the required IRM visibility, or would a separate record be needed?
Using IRM Professional, what extent of customization would typically be required—additional fields and relationships, or more substantial workflows, scripts and tables?
Have you implemented a similar approach? A practical example of the design and custom components would be helpful.
We are trying to establish the likely implementation effort before comparing this approach with native Risk Event Management.
