Auto approving

[Arun Priya]

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?

[Syed14]

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.

[Arun Priya]

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

[MaxMixali]

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.

[MaxMixali]

ServiceNow Solution: Routing SLA Request Approvals Based on Ticket Type (SC Task vs Incident)

-------------------------------------------------
Objective
-------------------------------------------------
Implement SLA Request approval logic that routes to different approvers depending on whether the related ticket is an SC Task or an Incident, while maintaining existing vendor and technical/non-technical branching.

-------------------------------------------------
1) Data Model
-------------------------------------------------
Table: u_sla_request
Fields:
- u_task (Reference → task)
- u_vendor (Reference → vendor table)
- u_is_technical (Boolean/Choice)
- u_approval_policy (Reference → approval matrix row for audit)

Approval Matrix Table (u_sla_approval_matrix):
- u_ticket_table (Choice: incident, sc_task, etc.)
- u_is_technical (True/False)
- u_vendor (Reference)
- u_approver_type (Choice: user/group/role)
- u_approver_ref (Reference to sys_user/sys_user_group/sys_user_role)
- u_fallback_approver (optional)
- u_order (integer)

-------------------------------------------------
2) Detecting the Ticket Type
-------------------------------------------------
function getTaskTableName(taskSysId) {
if (!taskSysId) return '';
var gr = new GlideRecord('task');
if (!gr.get(taskSysId)) return '';
return gr.getRecordClassName(); // 'incident', 'sc_task', etc.
}

-------------------------------------------------
3) Subflow: Resolve SLA Approver
-------------------------------------------------
Subflow Name: Resolve SLA Approver
Inputs: task_sys_id, vendor, is_technical
Outputs: result (JSON string)

Script Step:
(function execute(inputs, outputs) {
var taskTable = getTaskTableName(inputs.task_sys_id);
var m = new GlideRecord('u_sla_approval_matrix');
m.addQuery('u_ticket_table', taskTable);
m.addQuery('u_is_technical', inputs.is_technical ? true : false);
if (inputs.vendor) m.addQuery('u_vendor', inputs.vendor);
m.orderBy('u_order');
m.setLimit(1);
m.query();

var result = { approverType: '', approverRef: '', policy: '' };

if (m.next()) {
result.approverType = m.getValue('u_approver_type');
result.approverRef = m.getValue('u_approver_ref');
result.policy = m.getUniqueValue();
} else {
result.approverType = 'group';
result.approverRef = gs.getProperty('x_app.default_approval_group', '');
}

outputs.result = JSON.stringify(result);

function getTaskTableName(sysId) {
var gr = new GlideRecord('task');
if (!gr.get(sysId)) return '';
return gr.getRecordClassName();
}
})(inputs, outputs);

-------------------------------------------------
4) Main Flow (u_sla_request)
-------------------------------------------------
Trigger: On create or on status update requiring approval.

Steps:
1. Validate u_task, u_vendor, u_is_technical fields.
2. Call Subflow “Resolve SLA Approver”.
3. Parse result:
var cfg = JSON.parse(outputs['Resolve SLA Approver'].result);
4. Use “Ask for Approval” step:
- If cfg.approverType == 'user' → Approvers = cfg.approverRef.
- If 'group' → Approvers = group, set rule as “Anyone” or “All”.
- If 'role' → Resolve users with that role dynamically.
5. After approval, advance SLA Request state; on reject, mark Rejected.

-------------------------------------------------
5) Minimal Alternative (Hardcoded)
-------------------------------------------------
(function execute(inputs, outputs) {
var taskTable = '';
var taskId = current.u_task + '';
if (taskId) {
var gr = new GlideRecord('task');
if (gr.get(taskId)) taskTable = gr.getRecordClassName();
}
if (taskTable == 'sc_task') {
outputs.approverUser = 'SC_TASK_APPROVER_SYSID';
} else if (taskTable == 'incident') {
outputs.approverUser = 'INCIDENT_APPROVER_SYSID';
} else {
outputs.approverUser = gs.getProperty('x_app.default_approver','');
}
})(inputs, outputs);

-------------------------------------------------
6) Adding Project Closures
-------------------------------------------------
Include the project table in the approval matrix (u_ticket_table = 'pm_project') with its approver. The same subflow handles all ticket types.

-------------------------------------------------
7) Governance & Best Practices
-------------------------------------------------
- Validate u_task before proceeding.
- Allow multiple approvers using u_approval_sequence if needed.
- Configure escalation via Flow timeout or fallback approver.
- Store applied policy (u_approval_policy) for auditing.
- Use ATF tests to validate each routing path.

-------------------------------------------------
😎 Why This Is Best Practice
-------------------------------------------------
- Avoids multiple branch-heavy flows.
- Future-proof and maintainable (matrix-driven).
- Easily supports new ticket types and vendors.
- Business teams can manage approvers without Flow edits.

-------------------------------------------------
TL;DR
-------------------------------------------------
1. Create an Approval Matrix table keyed by ticket type, vendor, and technical flag.
2. Build a Resolve Approver subflow that reads this matrix.
3. In the main SLA Request Flow, call the subflow, then use “Ask for Approval” with the returned user/group.
4. Scales to SC Task, Incident, Project closures, etc.