Modifying ClaimContact roles

Reserved roles that are set from a field

For example, the reporter role is set from the Claim's reporter field. To add the reporter role to a ClaimContact, modify the Claim's reporter field so that it references the ClaimContact.

Suppose that there is a claim with ID cc:610 , and there is a ClaimContact with ID cc:1306. The following is an example of adding the reporter role to that ClaimContact:

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610

{
  "data": {
    "attributes": {
      "reporter": {
        "id": "cc:1306"
      }
    }
  }
}

Reserved roles that are set from an array

As another example, the witness role is set from the Claim's witnesses array. To add the witness role to a ClaimContact, add the ClaimContact the witnesses array.

Suppose that there is a claim with ID cc:610 , and there is a ClaimContact with ID cc:1306. The claim has no witnesses. The following is an example of adding the witness role to ClaimContact cc:1306.

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610

{
  "data": {
    "attributes": {
      "witnesses": [
        {
          "contact": {
            "id": "cc:1306"
          }
        }
      ]
    }
  }
}

Keep in mind that, within the system APIs, PATCHing an array does not add new members to the existing members. It replaces the existing members with the new members. If you want to add members to an array, you must first determine the existing members, and then specify an array with those members and the ones you wish to add. For more information, see PATCHes.

Reserved roles that are set through actions

In some situations, a reserved role is set when an action is executed on a resource other than the ClaimContact itself. For example, when a service request is created, the ServiceRequestInstruction can specify a ClaimContact as the CustomerContact. This ClaimContact is given the reserved role servicerequestparticipant.

JSON syntax for the editableRoles array

When POSTing or PATCHing a ClaimContact, every member of the editableRoles array must include three pieces of information:

• The role's code
• The type of object on which the ClaimContact has this role
• The ID of the object on which the ClaimContact has this role

The syntax used to specify this is:

"editableroles": [
  {
    "role": {
      "code": "<roleCode>"
    },
    "relatedTo": {
      "type": "<parentObjectType>",
      "id": "<parentObjectId>"
    }
  },
  ... <additionalRoles>

For example, the following PATCHes Claim cc:610 so that ClaimContact cc:777 has the alternate contact role (whose code is altcontact) on the claim itself.

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610/contacts/cc:777

{
  "data": {
    "attributes": {
      "editableRoles": [
        {
          "role": {
            "code": "altcontact"
          },
          "relatedTo": {
            "type": "Claim",
            "id": "cc:610"
          }
        }
      ]
    }
  }
}

Similarly, this example shows how to PATCH Claim cc:610 so that ClaimContact cc:208 has the owner role (whose code is incidentowner) on the vehicle incident whose ID is cc:102. (In other words, ClaimContact cc:208 is the owner of the vehicle specified in vehicle incident cc:102.)

PATCH http://localhost:8080/cc/rest/claim/v1/claims/cc:610/contacts/cc:208

{
  "data": {
    "attributes": {
      "editableRoles": [
        {
          "role": {
            "code": "incidentowner"
          },
          "relatedTo": {
            "type": "vehicleIncident",
            "id": "cc:102"
          }
        }
      ]
    }
  }
}

PATCHing editableRoles scenarios

Keep in mind that, within the system APIs, PATCHing an array does not add new members to the existing members. It replaces the existing members with the new members. If you want to add members to an array, you must first determine the existing members, and then specify an array with those members and the ones you wish to add. For more information, see PATCHes.

When PATCHing editableRoles, the following table details the possible request payloads and they way the system APIs will respond.