/api/helpdesk/processes/{processId}/activities/{activityId}/processTicketData

Exposes one activity below a ticket process.

Activity updates are applied to a fresh process snapshot and then validated as a complete graph. A PATCH body omits properties that must remain unchanged. Collections supplied in the body replace their complete corresponding collection. Activity identifiers are local to the process graph; clients must obtain them from the process detail response before sending a transition or condition reference.

The activity collection is returned by the parent process detail resource through its activities property. This endpoint deliberately exposes only resolved activity details and targeted updates, avoiding a duplicate GET operation at the same WebAPICore route. Activities belonging to parallel tickets remain available through the parent parallelTickets graph.

For the start activity of an active parallel ticket, ticketText must not be null. When it is empty, processTicketData must contain a non-empty concrete value or reference for subject; non-empty text alone is sufficient. Main-ticket activities may use ticketText:null. The process validator also requires the configured allowedActions and transitions to leave every reachable activity/status combination with a valid way to continue or end the ticket/process.

Example of an activity update which also replaces the required fields and allowed actions:

 PATCH /api/helpdesk/processes/{processId}/activities/{activityId}
 {
   "name": "Review",
   "requiredFieldKeys": ["priority"],
   "allowedActions": [42]
 }
 

Values assigned when activity is entered.

# Request
GET /api/helpdesk/processes/<processId>/activities/<activityId>/processTicketData HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>

# Response
HTTP/1.1 200 OK
Content-Type: application/json

{
    "map": {
        "property": {
            "field": "string",
            "valueString": "string",
            "referenceType": 0,
            "parallelTicketId": "1gbaadivo74cl9dlasjj794gt"
        }
    }
}

The status codes 400, 403, 404, 405, 406, 409, 413, 415, and 500 use the same ApiError JSON error format:

{
    "status": 404,
    "code": "route_not_found",
    "message": "The requested API route does not exist.",
    "details": []
}

Request and response schemas used on this page.