/api/helpdesk/processes/folders

Exposes process folders below /api/helpdesk/processes/folders.

The collection resource returns the protected root node. The root contains compact metadata for its direct processes and one shallow level of FolderSummary children. Clients resolve a child folder to obtain that folder's direct processes and next-level children. This keeps a large folder tree from being repeated in every response; no parentId query parameter is required.

The root has a stable, generated identifier and parentId=null. Every direct child refers to that root identifier in its parentId. Folder names and parent identifiers are the only persisted writable properties; read-only identifiers are accepted and ignored for GET-to-PUT/PATCH round-trips. PATCH updates are staged and persisted by commit; there is no separate move action. A normal DELETE is limited to empty folders. Recursive deletion is an explicit confirmation-protected DELETE action.

Returns the protected root node with compact direct-process metadata and child-folder summaries.

 GET /api/helpdesk/processes/folders
 

The response is the same shallow folder shape used by GET /api/helpdesk/processes/folders/{folderId}. Descendants are never embedded recursively.

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

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

{
    "id": "7fi86x9ejols3xlnjyden4b2r",
    "name": "string",
    "parentId": "84d5cu714nw2550gpmwkxnn5a",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "42pozwhcrbepki9pddagp82ld"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "a1vw7y50w7zlivsocfhhawaod",
            "parentId": "bqimc67khzp26oykywcyx0isn"
        }
    ]
}

Creates a staged folder.

Omitted or null parentId in the request body selects the root. Once committed, the response uses the stable root identifier as the new folder's parentId.

 POST /api/helpdesk/processes/folders
 {"name":"Customer onboarding","parentId":null}
 

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

{
    "id": "3yf5yhzv4k3oxg4fgpyiocofp",
    "name": "string",
    "parentId": "0j4w76zm6o3f2n06hnekcinet"
}

# Response
HTTP/1.1 201 Created
Content-Type: application/json

{
    "id": "7fi86x9ejols3xlnjyden4b2r",
    "name": "string",
    "parentId": "84d5cu714nw2550gpmwkxnn5a",
    "processes": [
        {
            "name": "string",
            "description": "string",
            "id": "42pozwhcrbepki9pddagp82ld"
        }
    ],
    "children": [
        {
            "name": "string",
            "id": "a1vw7y50w7zlivsocfhhawaod",
            "parentId": "bqimc67khzp26oykywcyx0isn"
        }
    ]
}

Hard-deletes this process definition and updates tickets through the manager's normal lifecycle. A subsequent GET of the process identifier returns 404; this operation does not leave an inactive process resource behind.

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

# Response
HTTP/1.1 204 No Content

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.

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

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

{
    "folderPath": "string",
    "id": "enwyrtl7k1l3g8j8xlpm4o1qw",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7f0aah0fqvvm55h2ey6uf9vcv",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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.

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

{
    "folderPath": "string",
    "id": "awu26w7l40bejq5lsxtpp0fze",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7f0aah0fqvvm55h2ey6uf9vcv",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

{
    "folderPath": "string",
    "id": "enwyrtl7k1l3g8j8xlpm4o1qw",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7f0aah0fqvvm55h2ey6uf9vcv",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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.

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

{
    "folderPath": "string",
    "id": "awu26w7l40bejq5lsxtpp0fze",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7f0aah0fqvvm55h2ey6uf9vcv",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

{
    "folderPath": "string",
    "id": "enwyrtl7k1l3g8j8xlpm4o1qw",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7f0aah0fqvvm55h2ey6uf9vcv",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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.