View Source

This table is used to provide information and a methodology for turning off or on some of the standard ITIL functions or modules, as you develop your own ITIL implementation. We wanted to make it easier to hide or show certain fields, and to run or eliminate certain rules, based on whether or not you want to use a particular function. We have tried to automate as much as possible, by tying the visibility of specific fields, tables, and rules to the selections made in this table.

The functions that have been predefined include the following:

Function Name	Description	Function Turned On?
Baselines	The Baselines table allows a configuration baseline to be created for a CI and stored for future reference or to be used to roll back unsuccessful changes. Baselines are related to individual configuration items. Using this to provide a rollback function would require the development of scripts.	No
Change Calendar	This controls the options to create calendar entries related to change requests.	Yes
CI Change Log	Agiloft can be integrated with an asset polling system, and any changes made through this integration or made by users to specific attributes can be captured automatically and pushed into the CI Change Log table. The information tracked includes the date/time the changes were made and the field values before and after the change. This information can be stored in a change log record linked to the CI that was modified.	No
Closure Categories	Closure Category is filled out upon completion of the requests that use them, and is typically used in reports. It is visible when the Status is Completed or some other terminal status (depending on the request table). The closure categories are set up for change requests, releases, incidents, service requests, and problems. The closure category of a release can be pushed to the related change requests automatically.	Yes
CSI Register	The CSI Register is a simple table for logging Continual Service Improvement suggestions and opportunities. These can then be linked into a Service plan as needed.	No
Definitive Media	The records in this table are used to store information about the physical or electronic location of copies of the code for software applications.	Yes
Event Management	Events are most commonly related to Configuration Items and used to notify about problematic conditions for a particular CI. But they may be related to other modules or conditions in the system, such as SLAs that have shown a pattern of breaching too often, or OLAs that are not being met consistently.	Yes
Knowledge Management	Records in the Knowledge Article table represent FAQs, policies, user guides, and other reference information that is helpful in maintaining and improving the ITIL process.	Yes
Release Management	Release Management is linked to Change requests and Configuration Items. It is typically used to manage a set of tasks related to a new release or upgrade of software or hardware configuration items. It has sophisticated task workflows that can include approval tasks.	Yes
Service Costs	Depending on the selected cost model, the cost information is entered in the service itself (when Fixed for the service), the tasks related to the service, or it is compiled by totaling the time spent on the request or the costs for items purchased as part of the request. When a service request or incident that is billable is completed, the Total Cost in that record is populated automatically by the system based on the entered data and the service's cost model.	Yes
Service Plans	The Service Plans table is used to gather information for Service Improvement Plans and Service Quality Plans and to manage implementation of service improvements.	No
SLAs	The SLAs table manages the service level agreements between the service organization and its customers. SLAs define specific SLA targets for response and resolution times for incidents and service requests. These SLA targets also define diagnosis and resolution times for problems. SLA targets are based on the priority of the request record and are applied or updated whenever the priority is set or changed.	Yes
Underpinning Agreements and OLAs	The Underpinning Agreements table holds records for all Operational Level Agreements and Underpinning Contracts negotiated between the IT department and specific internal teams or outside service providers, which includes information on OLA targets for various requests.	No

Each record in the functions table holds notes about how to completely turn the function on or off.

Example function notes for the Change Calendar function.

In several cases, turning the function on or off will hide or display linked fields in several of the related tables, but you will still need to either hide, unhide, activate, or deactivate the main table itself to make it appear or disappear from the left pane for all users. See Hide or Inactivate Tables for how to do this.

ITIL Documentation > ITIL Functions > image2017-11-13_17-22-38.png (Hide/Unhide/Inactivate tables)

Hide - This turns off visibility and access to the table in the left pane of the program for all users. It keeps their permissions intact to the table, but hides it.
Unhide - This turns on visibility and access to the table in the left pane for the admin group only. Other groups may be added as needed.
Inactivate - this disables all references to the table in other tables as well as disabling all access to the table in the left pane. Linked fields to the table are still visible to admin users in the layouts and field wizard of other tables but they cannot be moved, viewed, or edited. The table disappears from the table trees where users select tables, such as in setting permissions, setting up outbound email, and other areas in the program.
If a table has been inactivated previously, to activate it you must click on the Inactive Tables tab and then click a button to activate it.

In most cases, clicking the Hide or Unhide button is the best option and the easiest to reverse.

For the other fields whose visibility is controlled by the ITIL functions, the way this works is that we have set up a default value for a link to the appropriate record in this table in the tables where such visibility conditions need to be applied. For instance, in the Service Request table, we have four linked sets to specific records in the ITIL Functions table, one for Service Costs, one for Closure Categories, one for Knowledge Management, and one for SLAs. These links include the current value for the Function Turned On field for that record.

graphic of linked fields to the SLA Function included set

Then the relevant fields in the service request have visibility conditions so they appear only if, for instance, SLA Function Included=Yes. If you change the value of that field in the ITIL functions table from Yes to No, then this linked field within all existing service requests is immediately updated, and those fields are hidden, and vice versa.

Keep in mind that fields that are visibility controlled by the ITIL functions linked set value will only be shown to a user if that user's group has view access to the relevant "ITIL Function Included" field in that table. This is true of all visibility dependent fields: users only see the field if they have view permission to the parent field.

In addition, rules that set the SLA Due Date and targets only run if SLA Function included=Yes.

These linked sets are added to every table where they need to be used to control visibility or rules, making it easy to quickly show or hide a function once you decide whether you want to use it.