How can we automate Trigger flow for two cabs on servicenow

[Servicenow lear]

Hello All,

We recently went live with ServiceNow ITSM .  We have two BU using snow and they have each CAB.  The trigger of the CAB flow is triggered based on Approval group of the Service on the form. if the Support group has type : BU1 then trigger BU1 CAB flow else if type contains BU2 then trigger other.

Problem statement : However we are seeing that same group could be submitting change for either of the CABS and its causing lot of issue.  

Need resolution on : How can we or what should we do that Change request goes to right CAB ?  a field on the form which says impacted BU (drop down) or something else .. 

Please guide

[Dr Atul G- LNG]

Hi @Servicenow lear 

I worked as a Change Manager, and based on my understanding, there is no out-of-the-box (OOTB) field in ServiceNow that directly helps identify which Business Unit (BU) is impacted.

Do you have any method to identify the impacted BU using the Configuration Item (CI)?
If not, and there’s no existing solution, then you may need to create a custom field to capture the BU information. This field can then be used in the CAB (Change Advisory Board) flow to help determine the impacted BU.

[Ankur Bawiskar]

@Servicenow lear 

My views

-> Add a Custom field called "Impacted Business Unit" to the Change Request table and form, configured as a choice list (e.g., BU1, BU2).

-> Make the field mandatory for Change submissions.

-> Modify the Change Approval workflow or Flow Designer logic to trigger the appropriate CAB approval path based on the field's value.

• If Impacted BU = BU1, route to BU1 CAB approval group.
• If Impacted BU = BU2, route to BU2 CAB approval group

If my response helped please mark it correct and close the thread so that it benefits future readers.

[TejasSN_LogicX]

hi @Servicenow lear ,

Hello,

This is a common scenario when multiple Business Units (BUs) share the same ServiceNow ITSM implementation and have different CAB processes. Right now, your routing is tied to the support group type, which can overlap and cause misrouting.

Recommended best practices:

1. Introduce an explicit “Impacted BU” or “CAB Type” field

   • Add a mandatory field on the Change Request form, e.g., Impacted BU (choice list: BU1, BU2, …).

   • This makes it very clear which CAB a change should go to, regardless of who is submitting it or which group they belong to.

2. Drive CAB flow based on this field

   • Update your CAB approval/flow logic to use the Impacted BU field instead of support group type.

   • Example: If Impacted BU = BU1 → trigger BU1 CAB flow; if Impacted BU = BU2 → trigger BU2 CAB flow.

3. Keep support group separate from CAB routing

   • Support group should remain for assignment/fulfillment purposes.

   • CAB routing should be driven by business impact (Impacted BU), not the submitter’s group.

4. Optional enhancements

   • If there are multiple BUs beyond BU1/BU2, you can expand the choice list.

   • If services are clearly mapped to a BU in the CMDB, you can auto-populate Impacted BU from the service record to reduce manual input.

Summary:
Yes, the best practice is to introduce a clear Impacted BU (CAB) field. This avoids ambiguity and ensures the correct CAB approval workflow is always triggered. Support groups can overlap, but business impact (BU) is the correct driver for CAB approval.

Hope this helps!