What is an SLA in ServiceNow? (A Beginner’s Guide to Agreements)

[Shaah]

ServiceNow Personal Developer Instances (PDI) and Service Level Management

ServiceNow Personal Developer Instances (PDI)

A Personal Developer Instance (PDI) is a free, fully featured ServiceNow environment provided for learning, development, and testing. Developers sign up on the ServiceNow Developer Site, request a PDI (choosing the desired release version), and receive an instance URL with administrator credentials. The PDI comes preloaded with sample ITSM applications (Incidents, Change, etc.) and demo data, allowing users to explore functionality without risk to live systems. Within a PDI, you have full administrative rights to customize tables, workflows, UI, and business rules, and to build or test new applications or integrations.

PDIs have a few important limitations and usage rules:

• Single instance per user: Each developer account can have only one active PDI. If you need a different version or a fresh start, you must release the existing instance first.

• Inactivity expires: If a PDI is idle (no user logins) for about 10 days, it may be reclaimed by ServiceNow and permanently deleted. To keep it, log in and use it regularly. Always export or document key configurations before any long downtime.

• Not for production: PDIs are strictly for development/testing. Using a PDI for business or production purposes violates the licensing terms. Do not integrate critical systems or store real company data on it.

• Feature limitations: Some features are disabled on a PDI. For example, you cannot install ServiceNow Store applications (since the Instance is not licensed), and outbound email processing is typically turned off (no notifications go out). Otherwise, most platform capabilities (including REST/SOAP integrations, scripting, Flow Designer, etc.) work normally.

• Maintenance best practices: Use Update Sets or the ServiceNow applications to move changes between instances. Regularly back up important configurations by exporting update sets or lists of records. If your PDI becomes unstable, you can restart it from the developer portal or request a new one.

Using a PDI effectively:

• Experiment with trigger conditions, workflows, and flows without impacting production.

• Practice building reports, dashboards, and Performance Analytics on realistic data.

• Develop custom apps or extend existing modules (ITSM, HR, ITOM, etc.) to mirror company requirements.

• Test integrations via the REST or SOAP APIs in a safe environment.

• Prepare for certifications by practicing on a live instance.

PDIs can be updated or upgraded through the Developer Site if a new ServiceNow release is available. Remember to log in frequently and use your PDI as a sandbox: test out new features, develop improvements, and refine your ServiceNow skills with confidence.

 

SLA, OLA, and Underpinning Contract Management in ServiceNow

ServiceNow’s Service Level Management framework supports three key types of time-based agreements:

• Service Level Agreements (SLAs) – These are external commitments between the service provider and the customer or business. An SLA defines the agreed response and/or resolution time for an issue. For example, a Critical Incident SLA might promise resolution within 4 hours to the customer. In ServiceNow, SLA definitions attach to tasks (like Incidents or Requests) and automatically track elapsed time, breaches, and milestones. SLAs focus on the business’s expectations and satisfaction.

• Operational Level Agreements (OLAs) – These are internal commitments between support teams. OLAs ensure that back-end or supporting teams meet their deadlines so that the overall SLA can be met. For instance, if a Priority 1 incident is routed to a database team, an OLA might require the team to complete their work within 30 minutes. OLAs use the same engine as SLAs but apply internally. They answer the question: Did our internal groups do their part on time? OLAs help prevent a “blame game” by making each team accountable for its own part of the workflow.

• Underpinning Contracts (UCs) – These track service levels promised by external vendors or suppliers. If your organization relies on a third-party (for example, an internet provider or hardware vendor), the Underpinning Contract captures that external agreement. It measures the vendor’s response or resolution times as part of your overall service delivery. For example, if a server fails and has an external support contract, the UC might require the vendor to respond within 6 hours. ServiceNow can link UCs to specific Configuration Items (CIs) in the CMDB, so that the correct vendor SLA is applied automatically when that CI is involved.

These three agreements work together on the same task. All three timers can run simultaneously on an incident:

Feature Service Level Agreement (SLA) Operational Level Agreement (OLA) Underpinning Contract (UC)

Audience	External (customer/business)	Internal (support teams)	External (vendor/supplier)
Focus	Overall outcome and customer satisfaction	Internal handoff efficiency and performance	Vendor/supplier commitments and performance
Visibility	Reported to business leaders and customers	Used for internal management and metrics	Used for vendor management and contract reviews
Example	Respond to a critical ticket within 15 minutes	Network team investigates escalated ticket within 30 minutes	ISP provider responds to outage within 4 hours

In ServiceNow, SLA, OLA, and UC records are managed in the Service Level Management application (often found via the application navigator with keyword "SLA"). Each SLA definition includes a field to designate its Type (SLA, OLA, or Underpinning). When the specified conditions are met on a task record (for example, creating an incident or changing its priority), the system creates a Task SLA record for each matching SLA definition. That Task SLA record holds the actual countdown and status (e.g. remaining time, breached).

By separating agreements, ServiceNow provides end-to-end visibility:

• The SLA tells you if the promised service levels were met for the customer.

• The OLAs reveal which internal team (if any) delayed the process.

• The UCs show how well external vendors met their obligations.

Using all three allows for precise reporting and targeted improvements (rather than lumping all delays into a single metric). For example, if a ticket breaches its SLA, you can review the OLAs to see if any support team held it too long, or check the UC to see if a slow vendor response was the root cause.

 

SLA Configuration, Monitoring, and Reporting

Configuring SLAs

To configure service level agreements in ServiceNow, you create SLA Definition records under Service Level Management. Each definition specifies conditions and settings:

• Table and Conditions: Choose the target table (e.g. Incident, Change, or any task table) and a filter so the SLA only applies to relevant records (for example, priority = 1 or category = ‘Network’).

• Type: Indicate whether this definition is a standard SLA, an OLA, or an Underpinning Contract.

• Start Condition: Define the event that starts the clock, such as “on record creation” or “when state = In Progress.”

• Stop Condition: Define when the timer should end (typically when the issue is resolved or closed).

• Pause Condition: Specify if there are states or fields where timing should pause (for example, state = On Hold or Awaiting Info). The clock will automatically stop until the pause condition clears.

• Duration and Schedule: Set the target time (e.g. 4 hours, 2 days). You can measure either Business Hours (using an operating schedule) or Elapsed Time (continuous). Assign a business schedule (for example, Mon–Fri 9–5) if the service agreement only counts work hours.

• Workflow/Automation: Optionally tie the SLA to a flow or default workflow. This automation can send notifications or take actions at certain milestones (50%, 75%, breach).

For example, you might create an SLA definition:

• Name: “P1 Incident Resolution”

• Type: SLA

• Table: Incident

• Condition: [Priority] is 1

• Start: When incident is created

• Stop: When incident state = Resolved or Closed

• Pause: When state = On Hold or [Awaiting Vendor Info]

• Duration: 4 hours (using a 24x7 schedule for 24/7 support)

When an Incident meeting these criteria is created, ServiceNow automatically attaches a Task SLA record to it and starts the timer. If the stop condition is met before 4 hours elapse, the SLA is marked Completed; if the time runs out first, it is marked Breached. The system can send alert emails or take configured actions at percentage milestones or at breach time.

Key configuration tips:

• Minimize dot-walked fields in conditions: Using fields that frequently change (like fields on related tables) can lead to unexpected SLA behavior, since the SLA engine uses final field values. Prefer conditions on fields directly on the target record.

• Allow multiple SLAs: Decide whether you permit multiple instances of this SLA on one task. Usually set to false to avoid duplicates, unless you have reason to allow stacking.

• Test with Business Rules/Flows: By default, ServiceNow uses a background process or flow to trigger SLAs. Ensure your conditions match the data changes you expect (e.g., creating the record might trigger the SLA). Debug with logs if SLAs aren’t appearing as intended.

Monitoring SLAs

Once SLAs are configured, monitoring their real-time status is critical:

• SLA Timeline: On each task record (e.g. an Incident form), the SLA timeline related list (usually under a “Service Level” tab) shows all SLAs attached to that task. It displays start time, pauses, resumes, and the final status (Completed or Breached).

• Active and Breached SLAs: ServiceNow provides list views under Service Level Management to see Active SLAs (running timers) and Breached SLAs. These lists help support managers quickly identify which tickets are approaching or have missed their targets.

• Notifications and Escalations: You can configure email notifications or run background tasks at milestone percentages (e.g., at 50% or 75% of the duration) or on breach. For instance, at 50% the system might email the assigned user as a reminder, and at 100% (breach) it might email a supervisor or trigger an SLA breach event.

• Reporting on SLA Performance: Key performance metrics should be tracked over time, such as:

  • SLA Compliance Rate: Percentage of tickets meeting their SLA targets versus breaching.

  • Average Resolution Time vs. SLA: Compare average times to the SLA goal.

  • Number of Breached SLAs: Trends of breaches by week/month, by priority or service.

  • Outstanding SLAs: Current tasks close to breaching.

  • OLA and UC KPIs: Similar metrics can be applied to OLAs (e.g., internal handoff times) and UCs (vendor response times).

ServiceNow offers built-in dashboards and Performance Analytics (PA) for SLAs. For example, the SLA Overview dashboard can show charts of SLA trends, such as compliance percentage over the last 30 days, or SLA status by assignment group. Administrators can also create custom reports using the Report Designer:

1. Select the Task SLA table (or the Service Level Agreements table for definitions).

2. Pick fields like Priority, Business Elapsed Time, Breach status, etc.

3. Use filters (e.g. for specific service or timeframe).

4. Choose a visualization (bar chart, line graph, table) to highlight key trends.

5. Add the report to a dashboard and schedule it for stakeholders or export as needed.

Analyzing SLA data uncovers patterns (such as certain types of tickets frequently breaching or a particular team causing delays via OLAs) and drives process improvements.

 

Best Practices and Real-World Examples

Best Practices

• Align SLAs to Business Value: Define SLA targets that reflect customer or business needs, not internal convenience. For example, a hospital system might need 1-hour response to critical incidents, whereas a minor request could have a 24-hour target.

• Keep SLAs Measurable and Clear: Use objective conditions and avoid ambiguity. Clearly document when SLAs start, pause, and end. For instance, specify exactly which ticket states or priority levels trigger each SLA.

• Prefer Simplicity: It’s often better to have fewer, well-defined SLAs than many overlapping ones. Too many SLA definitions can cause confusion and maintenance overhead. Use categories and priorities wisely to group tickets under the appropriate agreements.

• Use Business Schedules: If support is limited to business hours, configure SLAs with a schedule so that off-hours or holidays don’t unfairly count toward the SLA. Conversely, for 24x7 support, use a 24x7 schedule.

• Leverage OLAs for Accountability: Use internal SLAs to ensure that departments coordinate. For example, if a help desk issues a ticket to the network team, an OLA can require the network team to respond within a set time. This makes internal handoff times visible and accountable.

• Tie Underpinning Contracts to CIs/Vendors: Maintain accurate CMDB data so that when an SLA involves a particular Configuration Item, the correct vendor contract is applied. Link Underpinning SLAs to vendors or contract records. This automates vendor SLA triggering and aids in vendor performance reviews.

• Review and Update SLAs Regularly: Include SLA targets in your change management or governance processes. When services change (e.g. new support hours), update the SLA definitions and inform stakeholders. Maintain an SLA catalog or documentation listing each SLA’s purpose, targets, owners, and schedules.

• Automate Monitoring and Alerts: Configure notifications for SLA breaches and milestone warnings. Consider using ServiceNow Flow Designer or Business Rules to automate follow-up actions (such as creating a high-priority task when a breach occurs).

• Use the PDI for Testing: Before applying new SLAs in production, prototype them in your PDI. Test different scenarios (e.g. pausing and resuming conditions) to make sure they behave as expected.

• Track KPIs with Reporting: Build dashboards (using native reporting or Performance Analytics) to regularly track SLA fulfillment rates, mean times, and breach counts. Use these insights in service reviews to drive continuous improvement.

Real-World Examples

• IT Help Desk (Example): A company’s service desk defines an SLA: Priority 1 Incidents (e.g. system outages) must be resolved in 1 hour. An OLA might require the escalation team to acknowledge any P1 incident within 10 minutes. If the incident involves a third-party (say, a cloud provider), an Underpinning Contract ensures the vendor responds within 2 hours. In practice, when a P1 ticket is created, three timers start: the 1-hour customer SLA, the 10-minute OLA for the internal team, and the 2-hour UC for the vendor. Dashboards show how many P1 incidents met the SLA each month and identify whether delays were internal or due to vendor response.

• HR Onboarding (Example): The HR department uses ServiceNow to track new hire onboarding requests. They set an SLA: All equipment and accounts must be provisioned within 5 business days of request. Internally, the IT group has an OLA to complete provisioning within 2 business days once HR submits a request. Suppose a request triggers an incident or task; the SLA ensures HR knows if the 5-day goal is met, while the OLA ensures IT stays on schedule. If the IT hardware vendor has a contract, a UC might track the vendor’s hardware delivery time. Management then reports monthly on SLA adherence for onboarding, using ServiceNow reports showing compliance rates.

• Managed Services (Example): A managed service provider (MSP) maintains SLAs for its clients: e.g. 99.9% uptime guarantee for client websites and 4-hour response for critical alerts. Internally, the MSP has OLAs between its own teams (network, server, security) so that if one team delays, the breach is tracked internally. When an alert is received, a network ticket creates a ServiceNow incident; the system automatically attaches an SLA based on the client’s contract. Reports are generated showing SLA performance by client, and any breaches are used in the MSP’s quarterly review meetings.

• E-commerce Platform (Example): An online retailer might have an SLA that every order inquiry ticket is responded to within 1 business day. An internal OLA might require the Tier 1 support team to assign or answer the ticket within 4 hours. If a ticket reveals a shipping issue with a vendor, a UC might be triggered with the shipping company’s contract (e.g. vendor must respond to the support ticket in 8 hours). ServiceNow ticket dashboards help customer service managers track how many inquiries meet the SLA and whether any department or vendor caused delays.

In each case, ServiceNow’s SLA framework (used on live instances, often starting in a PDI during development) automates the tracking of these commitments, provides transparency to all parties, and supplies data to measure and improve service delivery.

[BiswaRanjanRout]

An SLA (Service Level Agreement) in ServiceNow is a rule that tracks how long a task takes to be completed and checks whether it is finished on time.