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.

[XYZ]

Hello @Itallo Brandão ,

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

Here "CMDB App Support" mentioned here is dynamic group .ex:- if Business app A is selected, the task will be trigger to support group of application A(support group_A), similary if Selection is B , it would trigger a task to support group B(suppport group_B) .So basically if i understood it correctly, recommendation would be not to trigger seperate tasks to their respective support groups?? like A would to support group A, B would go to support group_B etc???Like in case our case if 30 different apps are selected, it should not trigger 30 different tasks(seperate tasks) to their respective support group?? Please help me to understand here.

Thanks!!

[Itallo Brandão]

Hi @XYZ ,

Thank you for the clarification! That is the most important question to ask.

Let me clarify the rule clearly so you don't break your process.

The Rule: "Different Support Group = Different Task"

If App A goes to Support Group A and App B goes to Support Group B, then YES, you must trigger separate tasks. You cannot assign a single task to two different groups.

The Logic of Consolidation (The "Bucket" Strategy)

My recommendation to "Consolidate" applies when multiple apps belong to the SAME group.

Example: Imagine the user selects 3 Apps:

1. Adobe Acrobat (Managed by: End User Computing)

2. Microsoft Office (Managed by: End User Computing)

3. SAP ERP (Managed by: ERP Team)

Bad Approach (3 Tasks):

• Task 1 -> End User Computing (Remove Adobe)

• Task 2 -> End User Computing (Remove Office)

• Task 3 -> ERP Team (Remove SAP) (Result: The "End User Computing" team gets spammed with 2 tickets for the same person).

Best Practice Approach (2 Tasks):

• Task 1 -> End User Computing (Description: "Please remove access to: Adobe Acrobat, Microsoft Office")

• Task 2 -> ERP Team (Description: "Please remove access to: SAP ERP")

Answering your specific question:

"Like in our case if 30 different apps are selected, it should not trigger 30 different tasks to their respective support group??"

• If those 30 apps are managed by 30 UNIQUE groups: Then YES, you must trigger 30 separate tasks. There is no way around this, as each team needs their own ticket to track their work.

• If those 30 apps are managed by only 5 groups (e.g., 6 apps per group): Then you should trigger only 5 Tasks, grouping the apps into the task for their respective owners.

Summary: You consolidate based on the Assignment Group, not the Application.

If this clarifies the logic for your design, please mark the response as Accepted Solution.

Best regards,
Brandão.

[XYZ]

Hello @Itallo Brandão ,

Could you please help me to understand how we can check which user has access to which application in cmdb? Is that mapping available? If not ,what would you recommend to get that mapping in service now.please let me know ow your thoughts on this

Thank you for helping me out on this requirement 

Thanks!