Closing activities

A general activity is closed either by completing it or skipping it. In order to be closed, the activity must be opened and assigned to a user. (Approval activities, which are discussed later in this topic, are closed in a different way.)

When closing an activity, there are two options for the request payload:

  • An empty payload
  • A payload with an included note. (This option is used when you want to create a note while you close the activity. The payload has no data section, but it does have an included section.)

All endpoints for closing activities are in the Common API.

Completing an activity

Completing an activity indicates that the corresponding action has been taken or the assignee is aware of the corresponding issue.

The following payload completes activity xc:1.

POST /common/v1/activities/xc:1/complete

<no request payload>

The following payload completes activity xc:1 and creates a note.

POST /common/v1/activities/xc:1/complete

{
  "included": {
    "Note": [
      {
        "attributes": {
          "body": "This activity  was completed through a system API call."
        },
        "method": "post",
        "uri": "/common/v1/activities/xc:1/notes"
      }
    ]
  }
}

Skipping an activity

Skipping an activity indicates that there is no longer a need to take the corresponding action. Activities have a mandatory Boolean field. If this is set to true, the activity cannot be skipped.

The following payload skips activity xc:1.

POST /common/v1/activities/xc:1/skip

<no request payload>

The following payload skips activity xc:1 and creates a note.

POST /common/v1/activities/xc:1/skip

{
  "included": {
    "Note": [
      {
        "attributes": {
          "body": "This activity was skipped by a system API call."
        },
        "method": "post",
        "uri": "/common/v1/activities/xc:1/notes"
      }
    ]
  }
}

Approving an approval activity

Approval activities are associated with actions that require approval from a user with sufficient authority, such as a manager. Approval activities are closed either by approving or rejecting the activity. This either allows or prevents the associated action.

Only approval activities can be closed by being approved or rejected. General activities must be closed by being completed or skipped.

Approval activities often involve financial activities, such as sending money to an insured or a third party. As an added layer of protection, caller applications may want to use checksums with calls to the /approve endpoint to ensure that no changes were made to the activity between the time it was retrieved and the time it is to be approved. For more information on checksums, see Lost updates and checksums.

When approving an activity, the options for the request payload are:

  • An empty payload
  • A payload with an approval rationale. (This is a string value that describes why the activity was approved or rejected.)
  • A payload with an included note.
  • A payload with an approval rationale and an included note.

The following payload approves activity xc:2.

POST /common/v1/activities/xc:2/approve

<no request payload>

The following payload approves activity xc:2 with an approval rationale.

POST /common/v1/activities/xc:2/approve

{
  "data":
    {
      "attributes": {
        "approvalRationale": "Higher reserve approved because claimant is gold-tier customer."
      }
    }
}

The following payload approves activity xc:2 with an approval rationale and a note.

POST /common/v1/activities/xc:2/approve

{
  "data":
    {
      "attributes": {
        "approvalRationale": " Higher reserve approved because claimant is gold-tier customer"
      }
    },
  "included": {
    "Note": [
      {
        "attributes": {
          "body": "This activity was approved through a system API call."
        },
        "method": "post",
        "uri": "/common/v1/activities/xc:2/notes"
      }
    ]
  }
}

There are currently no Cloud API endpoints that reject approval activities.