Correctly Utilizing Service Accounts in Flow Designer Integrations

[Ratnakar7]

When implementing ServiceNow, one common challenge arises with catalog items and OOB flows that enforce prerequisites. For example, the out‑of‑box Change Request catalog item requires that whoever initiates the request has the Change skill. This works fine for internal users, but what happens when external vendors need to initiate change requests- either through the Service Portal or via API - and they don't have the required skill?

Granting every vendor user elevated privileges is neither secure nor scalable. Customizing the OOB flow to skip the skill check risks breaking upgrades. The right answer lies in service accounts.

Service accounts are a cornerstone of secure ServiceNow implementations. They allow integrations and automated flows to run with the right permissions, without granting elevated privileges to every external user. But when working with Flow Designer, developers often hit a limitation: the Run As property only supports System User or User who initiates session. So how do you correctly leverage a service account when creating Change Requests through catalog items or APIs?

-> The Problem

• OOB prerequisite: Change Request catalog item requires the Change skill.

• Vendor limitation: Vendors submitting requests via portal or API don't have this skill.

• Failed requests: Submissions are blocked, notifications misfire, and integrations break.

-> The Wrong Approaches

• Granting vendors the Change skill

  • ✅Easy to implement

  • ❌Violates compliance and security best practices

  • ❌Creates audit headaches

• Customizing OOB flow logic

  • ✅Bypasses the skill check

  • ❌Unsupported by ServiceNow

  • ❌Breaks upgrade path and increases maintenance

-> Service Account Pattern

The recommended solution is to use a dedicated Service Account with the required skills and roles, and configure integrations to run under this account.

How it works

1. Create a Service Account

   • Technical user in ServiceNow with the Change skill and necessary roles.

   • Managed by IT, not tied to an individual.

2. Route vendor submissions through the account

   • Vendors authenticate via API credentials mapped to the service account.

   • Requests are created under the service account identity.

3. Capture vendor identity separately

   • Use catalog item variables or fields like Requested For or Vendor Contact.

   • This ensures audit trails reflect the true origin.

4. Notifications and audit

   • Notifications go to the vendor contact, not the service account.

   • Audit logs show the service account created the request, but metadata tracks vendor origin.

-> The Right Approaches

Option 1: Impersonation Custom Action (Exact Solution)

If you need the record to truly be created by the service account (so sys_created_by reflects that account), you can build a custom Script Action that impersonates the service account before creating the record.

Steps:

1. Create a Custom Action called Impersonate Service Account.

2. Add a Script step:

(function execute(inputs, outputs) {
   var userId = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx'; // sys_id of service account
   gs.getUser().impersonate(userId);

   var gr = new GlideRecord('change_request');
   gr.initialize();
   gr.short_description = "Vendor initiated change";
   gr.opened_by = userId;
   gr.requested_by = userId;
   gr.insert();
})();

• Place this action at the start of your Flow, followed by the "Create Change Request" action.
• Ensure the service account has the required Change roles and skills. 
  
  Pros: sys_created_by shows the service account. Cons: More complex, impersonation can raise audit/security concerns.

Option 2: Run as System + Field Mapping (Recommended)

For most implementations, it's easier and safer to let the Flow run as System User, then explicitly set the fields to the service account.

Steps:

1. In Flow Properties, set Run As → System User.

2. In the "Create Change Request" action, set:

   • opened_by → Service Account sys_id

   • requested_by → Service Account sys_id

Result:

• sys_created_by = system

• opened_by / requested_by = service account

• Business logic (approvals, notifications, reporting) works correctly.

Pros: Upgrade‑safe, simple, widely recommended. Cons: sys_created_by shows "system", not the service account.

->Best Practices

• Audit clarity: Always capture vendor identity in metadata.

• Security: Limit service account usage to integrations; rotate credentials regularly.

• Upgrade safety: Avoid modifying OOB flows; rely on service account privileges.

• Monitoring: Track service account activity to detect misuse.

-> Conclusion

Flow Designer's Run As limitation doesn't mean you can't correctly utilize service accounts. By choosing between impersonation (for strict audit needs) or Run as System + field mapping (for most cases), you can maintain compliance, preserve upgrade safety, and ensure smooth integrations. Service accounts are the correct way to bypass skill prerequisites without compromising security or breaking OOB functionality. 

Thanks,

Ratnakar