SLA'S are not getting attached for Incidents created by External Users
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Community,
I am facing an issue in a domain-separated instance regarding SLA attachment on incidents created through inbound email automation from external users.
Scenario:
- The instance is domain separated.
- SLA definitions are configured in the client domain.
- Incidents are being created in the same client domain through an inbound email action.
Expected Behavior:
When an incident is created via inbound email, the configured Incident SLAs should attach immediately if the SLA conditions are met.
Actual Behavior:
- For internal users, incidents created through the same automation have SLAs attached immediately.
- For external users, incidents are created successfully in the client domain, but no SLAs are attached initially.
- If any update is made to the incident (for example, updating the Short Description or Description), the SLAs attach immediately.
- Before making any update, if I switch my domain scope to Global and refresh the incident, I can see the SLAs.
- Those attached SLAs show their domain as the SPAM domain, even though the SLA definitions are configured in the client domain.
Additional Observations:
- The inbound action used for internal and external users is the same.
- Incident fields and SLA conditions appear to be satisfied at the time of creation.
- The issue occurs only for incidents created from external users.
Question:
Has anyone encountered a similar issue where Task SLAs are evaluated in an unexpected domain during inbound email processing in a domain-separated environment? Are there any known constraints related to domain separation, inbound email actions, guest/external users, or SLA evaluation context that could cause this behavior?
Any suggestions would be greatly appreciated.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @SRIGOWTHAMRT ,
>>When you say external users, are they present in the sys_user table? If not, what is the logic in your inbound action to create these incidents? Is it defaulting to the Guest user?
>>If it is the Guest user, may be SLA engine couldn't figure out which domain to insert the SLA records into.
>>Can you check which domain the Guest user belongs to? Also, please check if any duplicate SLAs are being created when you switch to the Global domain and update the incident (in the client domain)
This will help us assist you further!
Thank you,
Hemanth
Certified Technical Architect (CTA), ServiceNow MVP 2024, 2025,2026
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Hemanth M ,
Thank you for your response.
Please find below my observations:
- Incidents created from external emails use a default user that is present in the client domain.
- Before the inbound action script executes, the email is processed by the Guest user, which belongs to the Global domain.
- No duplicate SLA records are being created.
- When the incident is opened in the client domain, no SLA is attached initially.
- If I switch to Global domain scope and refresh the incident, I can see the SLA records in the related list.
- The SLA definitions themselves are configured in the client domain.
- The attached SLA records are showing under the SPAM domain.
- After making any update to the incident (for example, updating the Description or Short Description), the SLAs attach correctly and start functioning as expected.
- This behavior is only occurring for incidents created through inbound email from external users. Incidents created by internal users using the same automation attach SLAs immediately.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Could you please share your thoughts on this issue?
