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/operationsRoles
Here we list all the permissions by user role regarding the API:
| Admininistrator | Agent | Key User | User | |
|---|---|---|---|---|
| Actions Allowed | RETRIEVE 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:
| Field | Meaning |
|---|---|
| entity_id | The unique ID to identify the record. |
| type_id | The Type ID of the operation record (it is the numerical ID of the entity type: incident, request, change, etc.). |
| title | The title of the operation. A brief description. |
| category1 | The 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. |
| category2 | The 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. |
| category3 | The 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. |
| description | Extended description of the request. |
| status | It is the status of the operation. It is an important value to manage the lifecycle of the request. |
| priority_id | Priority of the operation: the importance from the working team perspective. |
| urgency_id | Urgency of the operation: the importance from the requester user perspective. |
| submit_username | The 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_username | User that is actually requesting a service. |
| assigned_group_id | Working team that is working to solve the request. |
| assigned_username | User 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_at | Creation date of the record. |
| updated_at | Date of the last update on the system. |
| closed_at | Closing date of the record. If a record changes status from closed to re-opened, the this date is reset to null. |
| archived | Every 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_at | Archived date of a request. |
| updated_by | The user that has lat updated the request. |
| deleted | Every 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_at | Deleted date of the request. |
| mailbox_id | The mailbox that will be used to send notifications regarding the Operation. If empty the default outgoing mailbox will be used (if set). |
| due_date | The agreed date for the resolution. |
| version | The 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. |
| solution | The solution of a request, that can be emailed to the requester user or exposed on the portal. |
| formtemplate_id | The formtemplate id of the record. |
