Sc_task created by showing as system instead of requestor who create RITM

[nitin51]

HI

for one instance of servicenow, Sc_task created by showing as system in the activity streams instead of requestor who create RITM.

and in other servicenow instance, showing requestor name. can i know from where this is happening please.

we are using workflow and not using set values as well in workflows in either instance.

SS attach is showing system, i want find out from where is this happening. please help me troubleshoot.

[raj chavan]

Hi @nitin51 
traditional Workflows do not allow you to manually define the “Run as” user behavior. By default, the Workflow context runs under the currently logged-in user’s identity. However, certain Workflow activities, like “Timer,” automatically switch the context to the “system” user, and all subsequent activities inherit this context. This is standard functionality and cannot be customized.

If you need precise control over the “Run as” behavior, it’s recommended to transition to Flows, as they provide the flexibility to explicitly define the user under which each action is executed.

[Community Alums]

Hi Nitin,

A. Verify Workflow Configuration

1. Check the Workflow for RITM:
   • Navigate to the RITM workflow in both instances.
   • Identify the activity or script that creates the sc_task.
2. Compare the "Run As" Configuration:
   • Ensure the workflow activities are configured to run as the user who initiated the request.

B. Inspect Business Rules

1. Review Task Creation Rules:
   • Look for any Business Rules on the sc_task or sc_req_item table that might override the opened_by or created_by field during task creation.
   • Check for differences between the two instances in these rules.

C. Examine Scripts

1. Check for gs.getUser() Usage:
   • Scripts that use gs.getUser() in one instance might be set to "System" by default in the other.
   • Look for script actions or custom code that might set the task creator as "System."

D. Compare System Properties

1. Search for Related Properties:
   • Check for system properties in both instances that might influence task creation or workflow execution.
   • Example properties to check:
     • glide.workflow.default_user

glide.sys.auto_assign.created_by


If you found this as useful please mark as helpful and accept as solution.

[nitin51]

HI All,

this is not only for tasks, this is happening for all records like incidents as well when created from mail. observed recently. @Community Alums @raj chavan 

[FilipVacula]

Hello Nithin,

From my experience, actions show under the system user when they are running asynchronously - such as via a triggered event or when workflow execution has to wait for a condition or a timer.

When it comes to emails, does the Sender email address of the inbound email match exactly the email associated with a User in the system (sys_user table, column email)? This would be my first step in the investigation.

You can also consider using the GlideImpersonate.impersonate function if the action is triggered by code.