Task Management

This page gives a practical example to status management between hotelkit and your system.

Check necessaties and a step by step walkthrough.

1 Characteristics
2 Functionality
3 Setup
- 3.1 Defining the Webhook
- 3.2 Request Type
- 3.3 Enable Request
4 Task Import
- 4.1 Task Creation
- 4.2 Getting Status Changes

Characteristics

Importing of tasks comes with special characteristics as a task can change its status and has a workflow to follow. The partner can import the tasks, created in his system, to hotelkit where the customer then can process it the same way as if it was in the partners system. The status changes will be pushed back to the partner. That way the partner controls the workflows as if the tasks was handled in his backend system.

Functionality

The status changes will be implemented as actions. When the task is created, the partner sends the initial actions with it.

The partner will be informed via a webhook request as soon as one action is triggered. If given, further possible actions of the task may be returned. That way all the logic and workflows are under control of the partner.

For this process the functionality message_import is necessary for creating the task. Setting up a working webhook is needed to get updates for the status changes.

Setup

Defining the Webhook

It has to be defined once and is valid globally for the partner:

PUT /setup/partner
{
    "webhook":"https://examplePartner.com/hotelkit "
}

Request Type

For every kind of task there should be an additional request type. In case the partner handles guest requests, repair requests and room service requests, there should be 3 request types set up as the customer may forward each of those types to different recipients.

The title of a task should clearly indicate what to do for this request. The details will be imported with content.

As stated the available status changes will be represented with actions. Therefore the referenceID of an item has to be submitted.

PUT /setup/requests
{
    "type":"guestRequest",
   
    "labelForCustomer":{
        "de_DE":"Gästewunsch",
        "en_US":"Guest request"
    },
    "content":true,
    "link":true,
    "title":true,
    "referenceID":true,
    "attachements":false,
    "enabledByDefault":true,
    "text":false,
    "sendRecipients":false,
    "hasActions":true
}

Enable Request

Before sending requests to a client, the requestType must be enabled for the respective client.

PUT /setup/customer
{
    "enabledRequests":["guestRequest"]
}

To check imports in your test-environment, please make sure you are set as a recipient to read the import. This only applies in the test-environment.

Task Import

At first the task will be created at POST /requests and after that the status may be changed several times.

Task Creation

For testing purposes an extra towel will be requested.

Getting Status Changes

The customer may now trigger an action with the buttons “Accept” or “Decline”. As “Decline” requests some more information (text), it will be triggered for documentation purposes.
As soon as a button is pushed, a request to the webhook is triggered:

If the status change was handled by the partner a 200 response must be sent to finish the synchronization. If there are no follow up actions available, there is no payload.

Follow up actions means that there are new possible states for the request.
The follow up actions will be returned in the response:

More Details on cinfigurations of actions can be found in the previous chapter Status Management