Trigger SC TASK FOR CMDB CPP SUPPORT TEAM

[XYZ]

Hello Community,

There is a requirement to trigger multiple sc tasks based on "yes/no" condition.The scenario is they want to remove access for cmdb applications while a offboarding ticket is raised for a user .It would include multiple applications and that would trigger a tasks to cmdb app support group to remove access for the applications..Then they mentioned that there might be case where a requestor may not have a idea what access a offboarded user has to cmdb apps.

I recommended to craete a sperate field to cmdb apps table which would populate cmdb business applications and based on single selection that would trigger a task to cmdb app support.


I have some questions:-

What if there are multiple selection  of apps like 10, 20,30.Is this implementation really recommended from ServiceNow best practice considering the fact that it would triger additional 10 tasks, SLA's, email notifications., task closures?? 

sECOND WHAT if the requestor has no idea on the access a user has to cmdb apps???How to handle this scenario.

PLEASE let me know your thoughts.

Thanks,
Sajal

[Itallo Brandão]

Hi @XYZ ,

This is a classic Offboarding architectural challenge. You are absolutely right to question the scalability of triggering 30 individual tasks.

To ensure a robust and secure process, you need to cover 4 key areas: Consolidation, UX, Operations, and Security.

Here is the breakdown:

1. Task Architecture: Do not create 30 tasks

Short Answer: No. The Best Practice: The rule is One Task per Assignment Group.

• Scenario A (Same Group): If the "CMDB App Support" group handles all 30 apps, generate One Single Task.

  • How: In Flow Designer, loop through the apps to build a String List. Create one task and paste that list into the Description (e.g., "Remove access for: App A, App B, App C...").

• Scenario B (Different Groups): Only create separate tasks if different teams need to do the work.
  
  

2. UX: Handling "The Requester doesn't know"

Do not rely on the manager's memory. ServiceNow should tell them.

• Solution: Use a Script Include + GlideAjax on the Catalog Item.

  1. Lookup: When the user is selected, the script queries the database for current access.

  2. Populate: Auto-fill the List Collector on the form.

  • Result: The Manager reviews the actual access instead of guessing.
    
    

3. Operational Risk: Is the Leaver a Support Agent?

If the user being offboarded is a member of a Support Group (e.g., Database Admins), simply removing app access is not enough.

• The Risk: If they remain in the group, tickets might still be auto-routed to them, or their open tickets will breach SLA.

• Action: Your flow must remove them from sys_user_grmember and reassign their active tasks to their manager.
  
  

4. Security Risk: The "Tipping Off" Problem

Crucial Point: If the user (Bob) is in the "Database Support" group, and you assign the offboarding task to that same group, Bob might see the ticket before HR speaks to him.

• The Risk: Insider Threat / Retaliation. Bob realizes he is being fired because he saw the ticket in his own queue.

• The Solution:

  1. Lockout First: The Flow must set locked_out=true and active=false before generating any manual tasks.

  2. Intelligent Assignment: If the leaver is a member of the target group, assign the task to the Group Manager instead of the group itself to maintain confidentiality.
     
     

If this comprehensive strategy covers your architecture and security concerns, please mark it as Accepted Solution.

Best regards,
Brandão.

[Tanushree Maiti]

Hi XYZ,

In your user case, once the request is approved, it is moving to cmdb team/other team who will remove access from apps. Fulfillment teams knows what they need to do. 

So it's absolutely fine to create multiple tasks based on selection of Yes/no field either from RITM/ SCTASK form as per your requirement. If Business wants you can automate this kind of request instead of doing it manually by Fulfillment team.

Regarding customize your cmdb table , its ServiceNow recommendation to adopt an "out-of-the-box" (OOB) first approach to minimize technical debt, simplify upgrades, and leverage built-in ITIL best practices .