---
title: "Configure Operation Level Specification"
slug: "configure-operation-level-specification"
updated: 2026-02-13T09:34:14Z
published: 2026-02-13T09:34:14Z
canonical: "help.symphonysummitai.com/configure-operation-level-specification"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.symphonysummitai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Operation Level Specification

You can configure the Operation Level Specifications (OLS) for Incident Management, Service Requests and Problem Management.

To Configure OLS for the specific module, perform the following steps:

1. Log in to the application as an **Admin**. Ensure you are the Service Level Manager for the selected Workgroup. If not you cannot create Operation Level Specification. An error is displayed as “*You do not have access to create the specification*”.
2. Navigate to **SLA** > **Operation Level** > **New Operation Level Specification**.

New OLS configuration screen is displayed. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/New OLS.png)

Figure: New Operational Level Specification
3. To configure OLS at the Tenant level, select and enter the required fields in the left layout of the configuration screen.

The following table describes the Field Description:

| **Field** | **Description** |
| --- | --- |
| Department | Select **Department** from the dropdown list. It will display a list of Tenants based on the configuration under **Admin** > **Tenant** for which the SLA module will be available. |
| Customer | Select **Customer** from the dropdown list. It will display the list of customers based on the configuration under **Admin** > **Customers** > **Customer** **List**. |
| Location | Select **Location** from the dropdown list. It will display the list of locations based on the configuration under **Admin** > **Infrastructure** > **Common** **Masters** > **Common** **Master** **Type**. |
| Date | Displays the system date and time. Example: 2025-07-10 12:42:25 PM |
| Service Name | Enter the **Service Name**. |
| Status | Displays the status of the OLS, following are the other Statuses available after configuration. 1. **New** - As a new OLS configuration is selected, the status by default is **New** and field is grayed. 2. **Approve** - This status is displayed when the OLS is approved from the approver. 3. **Publish** - This status is displayed If it is ready to publish. |
| Source Workgroup | Select **Source Workgroup**, the dropdown list displays all the workgroups under the selected **Tenant**. > [!NOTE] > Note > > **Source Workgroup** (the workgroup from which the Work Order is created) and **Target Workgroup** (the workgroup to which the Work Order is created) cannot be same. |
| Target Workgroup | Select **Target Workgroup**, the dropdown displays all the workgroups under the selected **Tenant**. > [!NOTE] > Note > > **Source Workgroup** (the workgroup from which the Work Order is created) and **Target Workgroup** (the workgroup to which the Work Order is created) cannot be same. |
| Service Level Manager | Displays the **Service Level Manager** name, it is displayed based on the service level manager configured for the Workgroup under **SLA** > **Configuration** > **Service** **Level** **Approver**. |
| Service Handling | Select **Service Handling** from the dropdown list. |
| Description | Enter a **Description** about this OLS configuration. |
| Services Offered | Displays the **CMDB** list. |
| Analyst | Displays a list of Analyst(s) from the selected **Target Workgroup**. |

DeadlinePerformanceMaintenanceApprovalsService CompositionFinancial DetailsContract DetailsTargetRiskValidation

The **Deadline** tab within OLS Configuration is designed to manage and define the time-based parameters for three modules such as Incident Management, Service Request, and Problem Management. This configuration tab allows administrators to set precise Service Level Objectives for each module to ensure timely responses and resolutions.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Deadline.png)Figure: Deadline Configuration

The following table describes the Field Description for Deadline configuration.

| Field | Description |
| --- | --- |
| Priority | Select **Priority** from the dropdown list. The list displays the available options based on the configured values. Example: If you are configuring for Incident Management then the values from **Incident** > **Configuration** > **Priority** are displayed |
| Category | Select **Category** and click **OK**. By clicking search icon ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/search icon(1).png) and it will display all the Categories in a tree structure. The list displays the available options based on the configured values. Example: If you are configuring for Incident Management then the values from **Incident** > **Configuration** > **Category** are displayed. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Category Tree.png)Figure: Category |
| Response Time | Enter Response Time in minutes. |
| Resolution Time | Enter Resolution Time in minutes. |
| Active | Used to activate or deactivate the specific OLS configuration. If selected, it displays the status for the configured record as **True**. If not selected, it displays the status for the configured record as **False**. |
| ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Add(2).png) | Click **Add** to add and save the configuration. |

This structure empowers organizations to systematically enforce deadlines, tailoring response and resolution expectations by priority and category for Incidents, Service Requests, and Problems thus helping meet customer commitments and improving overall service efficiency.

### Edit Deadline

To edit a **Deadline** that is configured, click on the Edit icon ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/edit icon(1).png) and perform the required changes. As you click the edit icon the configuration changes to the edit mode and you will be able to see a **Save** action.

Perform the required changes on configuration and click **Save** for the changes to take effect. ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/save(3).png)

Figure: Edit Deadline

The **Performance** tab in the OLS configuration screen is designed to capture and enforce internal expectations for service quality and operational readiness. This includes how much workload a support function is expected to handle, the application's responsiveness, and how quickly incidents must be addressed and resolved.

These parameters help align internal teams with the agreed performance standards to ensure consistent delivery of services that support the overall SLA targets.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Performance.png)

Figure: OLS Performance Attribute Configuration

**Required Capacity**: This defines the minimum capacity (e.g., resources, personnel, infrastructure) that the operational team must ensure is available to support the service. Example: 10 agents should be available at all times to handle Level 2 support tickets.

**Service Usage**: Specifies the acceptable limits of usage or workload the internal team can handle over a specific time frame Example: 500 tickets per day.

**Response Time from Application**: Indicates the maximum time the associated application should take to respond to an action or request initiated by the internal team. Example: Application must respond to data retrieval requests within 2 seconds.

**Response and Resolution Times**: Response Time: Time taken by the internal team to acknowledge or begin working on an issue after it is reported. Example: Acknowledgment within 15 minutes of ticket assignment.

Resolution time: Time by which the issue should be fully resolved and service restored. Example: Critical issues must be resolved within 4 hours.

The **Performance** tab ensures the internal operations team is informed about what is expected of them in terms of resource allocation, system response behavior, and turnaround times. Defining these parameters correctly supports effective service delivery, avoids SLA violations, and improves collaboration across service functions.

The **Maintenance** tab in the OLS configuration screen is intended to define protocols and expectations related to planned or unplanned maintenance activities, especially those occurring during emergencies. This ensures that internal teams are aligned on how to respond and act when critical service components require urgent intervention or updates.

By capturing these details within an Operational Level Specification, organizations can maintain service continuity, minimize risk, and ensure that emergency actions are authorized and traceable.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Maintenance.png)Figure: Configure OLS Maintenance

**Maintenance Requirements (In Case of Emergency)**: This field captures the predefined requirements, steps, or conditions under which emergency maintenance can be carried out by the operational team or vendor. Example: Downtime window allowed only between 10 PM–12 AM with prior 30-minute notice to all stakeholders.

**Attachment Upload * :** This is a required field that you must upload a supporting document outlining the emergency maintenance process, approvals, contact list, or any contingency plan related to the entry in the text field. Example: Emergency maintenance standard operating procedure (SOP), Emergency contacts List, Risk assessment or impact analysis report, Downtime mitigation plan or rollback procedure.

The **Approvals** section is a critical section in the OLS configuration process that facilitates structured review and formal agreement between the internal teams involved in service delivery. This section ensures that both the **Source Workgroup** (the provider of the service) and the **Target Workgroup** (the consumer or dependent team) approve the defined OLS terms before they take effect.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Approvals.png)Figure: OLS Approvals Configuration

By involving both parties in the approval loop, this tab promotes transparency, accountability, and alignment on service expectations. Approver from the **Source Workgroup** and **Target Workgroup** must approve the OLS.

For more information, refer to the following Field Description:

| Field | Description |
| --- | --- |
| Approver | Displays the Approver name of based on the selected **Source Workgroup**. |
| Status | Select **Status** option from the dropdown list. Options displayed are as follows: - Approved: To Approve the OLS - Rejected: To Reject the OLS |
| Remarks | Enter **Remarks**, this is a field where the approver can provide comments, justifications, or feedback regarding their approval decision. |

The **Service Composition** section is designed to define the building blocks of a service that relies on operational collaboration between internal teams (workgroups). This section captures which internal workgroup is responsible for delivering a part of the service and what operational parameters must be in place for the service to function effectively.

The tab provides flexibility by allowing the configuration to be marked as **Internal**, which adjusts the validation requirements for the fields accordingly. This enables organizations to handle both formal OLA-based services and informal, internal-only dependencies.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/cs(1).png)Figure: OLS Service Composition Configuration

Refer the following table for Field Description:

| Field | Description |
| --- | --- |
| Internal | When selected, it denotes that the service composition is just **internal**. All other fields in this section become **non-mandatory**, allowing for quicker internal configurations without enforcing strict documentation. Example: You can select for, informal service dependencies or internal drafts not yet requiring approval or detailed scope definition. |
| Service Provider* | Select **Service Provider** from the dropdown. The displayed list is the internal team or workgroup responsible for providing the underlying service or operational support. |
| Remarks* | Enter **Remarks**, you can enter where additional comments, context, or notes about the service composition can be provided. |
| Attachments | Upload file to attach supporting documentation related to the service, workgroup responsibilities, or OLA dependencies. This field is optional. |
| Service Name* | Enter **Service Name**, it is the name or identifier of the internal service that is being referred to. |
| Operational Level Agreement* | Select **Operation Level Agreement**. it is the agreement that outlines the responsibilities, timelines, and expectations from the Service Provider |
| Required Changes* | Enter **Required Changes**, this is a field to capture any requested modifications to the existing OLA. If the OLA is not sufficient for the service to be established. |
| Fields marked with * Asterisk are Mandatory fields. |

The **Financial Details** tab is designed to capture the cost-related information associated with delivering the operational service defined in the OLS. This section enables organizations to track, manage, and justify internal costs of service provision, which is especially important for budgeting, cost optimization, and internal chargeback or cost allocation processes.

By recording cost types, accounting methods, and currency, this tab helps align financial accountability with service delivery expectations.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Financial Details(1).png)Figure: OLS Financial Details Configuration

For more information, refer to the following Field Description:

| Field | Description |
| --- | --- |
| Cost Type | Select **Cost Type** from the dropdown list. Categorizes the nature of the cost being recorded. Helps break down service costs into identifiable categories for better tracking and analysis. - **AMC Cost**: Annual Maintenance Contract cost, recurring cost for ongoing support or maintenance services. - **Base Cost**: Standard cost of providing the service without additional overheads or modifications. - **Cost Increased**: Represents any additional or escalated costs due to changes in scope, inflation, resources, etc. |
| Cost | Enter **Cost** value, this is the numerical value (amount) associated with the selected Cost Type. |
| Accounting Method | Enter **Accounting Method**, this field specifies how the cost is accounted for within the organization’s financial system. Examples: - Accrual-based accounting - Cash-based accounting - Cost Center Allocation Ensures financial records align with organizational accounting policies and reporting frameworks |
| Currency | Select **Currency** from the dropdown. The selected value is the currency in which the cost is recorded. Example: INR, USD, EURO, POUNDS |
| Date | Select **Date**, this is the date on which the financial entry is recorded or becomes effective. |
| Remarks | Enter **Remarks** to capture additional details, context, or justification for the cost entry. |

The **Contract Details** tab is used to define the contractual timeline, termination clauses, business relevance, and warranty coverage for the operational service being configured. It ensures that both technical and business teams understand the formal obligations, service boundaries, and customer-side dependencies. This adds legal and operational clarity to the OLS.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Contract Details.png)Figure: Contract Details

### Contract Duration

This section specifies the duration of the agreement, why the contract exists, what business processes it supports, and what outcome is expected. It helps link operational performance with strategic business intent.

For more information, refer to the following Field Description.

| Field | Description |
| --- | --- |
| Start Date | Select **Start Date**, this is the date on which the OLS contract becomes active. |
| End Date | Select **End Date**, this is the date on which the OLS contract ends. |
| Termination Rules | Enter **Termination Rules**, conditions under which the agreement can be terminated before the end date. |
| Business Justification | Enter **Business Justification**, explaining why this operational agreement is being created. |
| Process / Activities | Enter **Process / Activities**, list the business processes or customer-side activities supported by this operational service. |
| Desired Outcome | Enter **Desired Outcome**, the expected result or performance impact of the service being provided. |

### Warranty

This section captures information related to the warranty coverage for the service or solution components being delivered under the OLS. It includes the duration of the warranty and supporting documents.

For more information, refer to the following Field Description:

| Field | Description |
| --- | --- |
| Start Date | Enter **Start Date** this is the date from which the warranty period begins. |
| End Date | Enter **End Date**, this is the date on which the warranty expires. |
| Attachments | Upload field for supporting warranty documents or agreements. |

The **Risk** tab is designed to assess the **business criticality** and **operational impact** of the service being defined under the OLS. This section ensures that risk exposure is evaluated based on the importance of the service to vital business functions (VBFs), dependencies on critical assets, and the potential impact of service failure or degradation.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Risk.png)Figure: OLS Risk Configuration

#### Service and Asset Criticality

Identifies which business functions and assets are supported by the service, and assesses the associated business risk if the service becomes unavailable.

**VBFs Supported**: Lists the critical business functions or operations that depend on this service.

**Other Critical Assets**: Lists **non-VBF assets** (applications, databases, infrastructure components) that are crucial for the service to function.

**Business Justification**: Enter a description of the consequences or severity of impact on the business if the service fails or is disrupted.

The **Target** tab defines the operational performance goals that the source workgroup must meet for **incident handling** and **request fulfillment**. It captures measurable targets such as response and resolution times based on different priorities. This ensures that internal service levels are clearly defined and aligned with organizational or customer expectations.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/target.png)Figure: OLS Target Configuration

### Incident Management Targets

This section sets the expected **Response** and **Resolution** times for different **incident priorities**. These targets ensure that critical incidents are addressed faster than lower-priority ones and help track internal compliance with SLA-driven commitments.

For more information, refer to the following Field Description.

| Field | Description |
| --- | --- |
| Priority | Select Priority from the dropdown. Represents the severity level of the incident (example: Critical, High, Medium, Low). |
| Response Target | Enter Response Target. The value entered here is represented as % hence, it is the percentage of incidents (of a given priority) that must be responded to **within the defined SLA time.** Example: For P1 incidents: 95% is the Response Target, then 95% of P1 incidents must be acknowledged within SLA-defined time (example: 15 Minutes). |
| Resolution Target | Enter Resolution Target. The value entered here is represented as % hence, it is the percentage of incidents that must be resolved **within the agreed SLA time**. Example: For P2 incidents: 90% is the Resolution Target, 90% of P2 incidents must be resolved within the SLA (example: 4 Hours). |
| Effective Date | Select Effective Date, specifies from when the Targets become active or enforceable. |
| ![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Add(1).png) | Click **Add** to save the configuration in the Incident Management Target. |

### Request Fulfillment Targets

This section mirrors the incident targets but is focused on **service requests** (example: password resets, access requests, software installations). These targets help manage the delivery expectations of routine service tasks. For Field Description, refer to the Table described above.

The **Validation** tab serves as a final checkpoint in the OLS configuration process. It captures the review and validation activity, ensuring that the Operational Level Specification has been properly assessed before it becomes effective. This tab helps document **who validated** the configuration, **when** it was done, **what the outcome was**, and whether any **improvements or observations** were recorded.

It provides **traceability**, **approval assurance**, and helps identify areas for **service optimization**.

![](https://cdn.document360.io/62351b42-cfbd-43ad-8ce1-82b8f455337f/Images/Documentation/Validation.png)Figure: OLS Validation Configuration

For more information, refer to the following Field Description:

| Field | Description |
| --- | --- |
| Validation Date | Select **Validation Date**, this is the date on which the OLS configuration was reviewed and validated. |
| User Name | Type in the user name or click search icon to find and add the user. This is the user performs the validation. |
| Status | Select the Status from the dropdown, this is the result of the validation process. The values in the dropdown are: - Good - Bad - Improvement |
| Service Improvement Notes | Enter Service Improvement Notes for feedback or recommendations provided during the validation process. |

Refers to different entities or organizations using the SymphonyAI application, often with separate data and configuration settings

Defines the urgency or importance level for the respective Module

Specifies the type or classification of the Incident, Request or Problem.

The maximum allowable time within which a response to the Incident / Request or Problem must be given.

The maximum allowable time within which a Resolution to the Incident / Request or Problem must be given.