/api/helpdesk/processes/{processId}/startActivityId

Exposes stored ticket-process definitions and their import/export lifecycle.

The endpoint is request-local. Its writable properties are copied into an immutable TicketProcess only in commit. Consequently a PATCH changes only supplied properties, while a client can replace the complete process graph by supplying all process properties. The graph is validated before any manager operation is performed.

Both PUT /api/helpdesk/processes/{processId} and PATCH /api/helpdesk/processes/{processId} use this same model-update contract. Only properties annotated with Set may be supplied; omitted properties retain their current values, explicit null clears a nullable property unless the property's documentation defines a defaulting rule, and explicit null for a non-nullable property is rejected with 400 process_invalid. Collections such as activities and parallelTickets are replaced as complete collections. Read-only response properties such as id and folderPath are accepted and ignored for GET-to-PUT/PATCH round-trips; the identifier in the URL selects the process to update. A native export also has no folderId; omit it to keep the current folder, or send it explicitly when moving the process.

For example, to apply a complete exported graph:

 PATCH /api/helpdesk/processes/8ut68taio3kfeap4pwjcdh4fi
 Content-Type: application/json

 {"name":"Baugenehmigungsverfahren API-Test",
  "description":"Updated description",
  "activities":[...], "startActivityId":"activity-start",
  "parallelTickets":[...], "autoResourceAccess":"NONE",
  "canBeChangedWhenActive":false}
 

Process definitions use existing model identifiers. For example, an automatic transition can refer to an activity and an action as follows:

 {
   "name": "Incident handling",
   "startActivityId": "activity-start",
   "activities": [{
     "id": "activity-start", "type": "Standard", "name": "Start",
     "requiredFieldKeys": [], "allowedActions": [], "processTicketData": {},
     "followUpActivities": [{
       "nextActivityId": "activity-finish", "actionid": 123,
       "actionLabel": "Finish", "conditionsForAutoTransition": []
     }]
   }, {
     "id": "activity-finish", "type": "FinishProcess", "name": "Finish",
     "requiredFieldKeys": [], "allowedActions": [], "processTicketData": {},
     "followUpActivities": []
   }],
   "parallelTickets": [],
   "autoResourceAccess": "NONE",
   "canBeChangedWhenActive": false
 }
 

Dependencies are represented by typed condition records. For example, a transition that may run after an activity was completed uses the activity identifier in the condition-data JSON string; a parallel-ticket dependency uses the parallel-ticket identifier instead:

 "conditionsForAutoTransition": [
   {"type":"activityFinished",
    "conditionData":"{\"itemId\":\"activity-review\",\"ignoreIfNoLongerReachable\":false}"}
 ]

 "startCondition": [
   {"type":"ticketFinished",
    "conditionData":"{\"itemId\":\"parallel-audit\",\"ignoreIfNoLongerReachable\":true}"}
 ]
 

Use activityVisited when completion is not required, ticketHasValue for a field comparison, and allTicketsFinished when every configured parallel ticket must finish. allTicketsFinished is valid only on a main-ticket automatic transition and only when at least one parallel ticket is configured. The condition type and condition-data shapes are discoverable from the metadata endpoint; all conditions in one list must be fulfilled (logical AND).

The start activity of an active parallel ticket must contain non-null ticketText. If that text is empty, its processTicketData must provide a non-empty concrete value or reference for the subject field. A main-ticket activity may use ticketText:null. Validation also checks the complete action graph: every reachable activity/status combination must have an allowed action and transition to continue or end the ticket/process. Therefore a transition using an action such as action ID 1 can still be invalid when the activity's allowed actions do not make the resulting graph reachable.

Use the process editor metadata endpoint to discover valid action identifiers, activity types, condition types and ticket-field operators. Conditions in one condition list are evaluated as an AND expression. The model's condition data must use the exact shape returned by that metadata endpoint.

Identifier of the activity where the main ticket starts. An explicit null selects the first activity as the start activity when the graph is non-empty.

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

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

"5zg6jaqih89s29dsl0lrge97f"

Identifier of the activity where the main ticket starts. An explicit null selects the first activity as the start activity when the graph is non-empty.

# Request
PUT /api/helpdesk/processes/<processId>/startActivityId HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json

"cszyvsyxb6bxuns2ke9mzgjjv"

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

"7nl0ntdq71zyd3gf3n6ds0hjt"

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.