Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Auto approving

Arun Priya
Tera Contributor

We have created a customized table for SLA request. For non technical and technical ticket if the request is raised for SC Task it should go for one approver If incident it should go for another approver. This SLA request already having a flow design based on the vendor and technical and non technical type. Do anyone have idea to implement on this?

1 ACCEPTED SOLUTION

kaushal_snow
Giga Sage

@Arun Priya ,

 

You can use Flow Designer in ServiceNow to trigger when a record is created or updated on your custom SLA request table, then add conditions like if type == SC Task > Ask for Approval by approver A and else if type == Incident > Ask for Approval by approver B, and for each branch you can include an Update Record action to automatically mark the approval as approved or rejected (or skip the ask step entirely if it should auto approve)..........

 

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

 

 

Thanks and Regards,
Kaushal Kumar Jha - ServiceNow Consultant - Lets connect on Linkedin: https://www.linkedin.com/in/kaushalkrjha/

View solution in original post

7 REPLIES 7

Syed14
Mega Guru

You can add these new requirements to the same flow. Use if else logic and ask for approval action to implement this. If you need further help you can share your flow.

But how to check if it is from incident or task. Both are from different table

If it is customize table, you can create a custom reference field for task to differentiate between incident and sc task. 

MaxMixali
Kilo Sage

Got it—here’s a clean, scalable way to implement your SLA Request approvals in ServiceNow so they route to different approvers based on ticket type (SC Task vs Incident) while still honoring your existing vendor and technical / non-technical logic.

 


 

 

target architecture (simple + maintainable)

 

 

Key idea: don’t hard-code approvers in the Flow. Create a small Approval Matrix and a Resolve Approver subflow. Your main Flow just asks, “What ticket type is this SLA request tied to?” and “What approver does the matrix say?”—then sends the approval.

 


 

 

1) Data model (fields you need on your SLA Request table, e.g.,

u_sla_request

)

 

 

  • u_task (Reference → task)

    The originating record (can point to incident, sc_task, etc.)

  • u_vendor (Reference → core_company or your vendor table)

  • u_is_technical (True/False or Choice: Technical / Non-Technical)

  • (Optional) u_approval_policy (Reference → the approval matrix row that matched, for audit)

 

 

 

1a) Approval Matrix table (recommended)

 

 

Create u_sla_approval_matrix with these columns:

 

  • u_ticket_table (Choice: incident, sc_task … or free text)

  • u_is_technical (True/False)

  • u_vendor (Reference)

  • u_approver_type (Choice: user, group, role)

  • u_approver_ref (Reference to sys_user OR sys_user_group OR sys_user_role)

  • (Optional) u_fallback_approver (Reference to user/group)

  • (Optional) u_order (integer, in case of multiple matches)

 

 

This matrix keeps your Flow simple and future-proof—adding a new combination becomes just one new row, no Flow edits.