Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
What is the purpose of the "SLA Due", "Made SLA" and "Escalation" fields on the Task record? - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • What is the purpose of the "SLA Due", "Made SLA" and "Escalation" fields on the Task record?
KB0685189

What is the purpose of the "SLA Due", "Made SLA" and "Escalation" fields on the Task record?


11491 Views Last updated : Jul 24, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

Before the introduction of the SLA Engine (in the "Fall 2010" release), SLAs were processed by the "Escalation" engine that allowed each Task record to be associated with a single SLA. The fields "SLA Due," "Made SLA," and "Escalation" were maintained by the Escalation engine. This legacy SLA engine is still the only one used in Express instances.

The modern SLA engine improves on the original by allowing multiple SLAs to be tracked against each Task record. Users can understand if a particular Task SLA record has breached by viewing the individual Task SLA records - for the 2010 engine the Stage field will show Breached and in the 2011 engine a new "Has breached" field is used.

The Escalation engine is still present and running in the system as it also supports Inactivity Monitors (For more information on Inactivity Monitors, pls see product documentation topic 't_SetAnInactivityMonitor'.), even if you are using the SLA plugins, and this server-side code might change the value of the made_sla field when the task is closed.

If there are existing task records in the system that have the legacy SLA fields populated, they could be old records created in earlier releases. However, this does not impact the modern SLA engine in any way. The legacy fields can be ignored. Further, because the values may change unexpectedly, they are not intended for customer use.

If you still see new task records being created with values populated for these legacy fields, then you can check if they are intended to be used by verifying the System Property "com.snc.sla.run_old_sla_engine" to check if your instance is still configured to use the legacy Escalation engine for Service Level Agreements. If the property is false, you know the fields are reserved (because they are manipulated by the system) but the contents are not relevant. You can also check the contents of the legacy Service Level Agreements definition table ("sysrule_escalate"). Be aware that depending on how you access this table you might see both legacy SLA definitions and Inactivity Monitor definitions.


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.