Service Operation API

The Service Operation entity is used to manage Operations (tickets) in Deepser.
Service Operations can be accessed by every user.

Endpoints

http://deepserhost/api/rest/service/operation/[id]
http://deepserhost/api/rest/service/operations

Roles

Here we list all the permissions by user role regarding the API:

 AdmininistratorAgentKey UserUser
Actions AllowedRETRIEVE
CREATE
UPDATE
DELETE
RETRIEVE
CREATE
UPDATE
DELETE
RETRIEVE
CREATE
UPDATE
DELETE
RETRIEVE
CREATE
UPDATE

Fields

Here we list all the fields of the entity to describe their meainings in Deepser:

FieldMeaning
entity_idThe unique ID to identify the record.
type_idThe Type ID of the operation record (it is the numerical ID of the entity type: incident, request, change, etc.).
titleThe title of the operation. A brief description.
category1The category (1st level) of the operation. It is an important field to manage the assignment to working teams and to catalog correctly the scope of the activity requested.
category2The category (2nd level) of the operation. It is an important field to manage the assignment to working teams and to catalog correctly the scope of the activity requested.
category3The category (3rd level) of the operation. It is an important field to manage the assignment to working teams and to catalog correctly the scope of the activity requested.
descriptionExtended description of the request.
statusIt is the status of the operation. It is an important value to manage the lifecycle of the request.
priority_idPriority of the operation: the importance from the working team perspective.
urgency_idUrgency of the operation: the importance from the requester user perspective.
submit_usernameThe user that has created the record (he can be different from the Requester User that is the user actually requesting an activity). Think about a secretary that is submitting a request on behalf of his boss. The Submit User is the secretary, while the Requester User is the chief officer.
requester_usernameUser that is actually requesting a service.
assigned_group_idWorking team that is working to solve the request.
assigned_usernameUser that has taken in charge the request. He is typically an Agent or a Key User. Deepser lets you assign also to end users if we decide that they can be part of the resolution process.
created_atCreation date of the record.
updated_atDate of the last update on the system.
closed_atClosing date of the record. If a record changes status from closed to re-opened, the this date is reset to null.
archivedEvery Operation can be archived, for example we can archive all closed Operations of the past 5 years to hide them in the standard grids (but we could see them in the Archived grid).
archived_atArchived date of a request.
updated_byThe user that has lat updated the request.
deletedEvery Operation can be deleted setting the status to “Deleted” (or other status belonging to the Deleted class). All deleted requests will not be physically deleted from the database, but they will be only marked as deleted (soft delete, so they will be visibile in the Deleted grid). To delete physically use the button “Delete”. The record will not be recoverable anymore.
deleted_atDeleted date of the request.
mailbox_idThe mailbox that will be used to send notifications regarding the Operation. If empty the default outgoing mailbox will be used (if set).
due_dateThe agreed date for the resolution.
versionThe version of the request. Deepser stores in its DataBase every version of the Operations. We can always know the changes, the user that made a change and the date.
solutionThe solution of a request, that can be emailed to the requester user or exposed on the portal.
formtemplate_idThe formtemplate id of the record.