/api/helpdesk/processes/editor-metadata

Describes all selectable values and dependency rules required by a ticket-process editor.

The response is deliberately derived from the same action and field providers as the legacy editor. Clients must use the returned identifiers instead of hard-coding action IDs, condition identifiers, field keys, or operators. Condition examples are JSON fragments for the conditionData JSON string in a process-definition request. Multiple conditions in one list are evaluated as an AND expression. The contexts and constraints properties describe cross-object dependencies which cannot be inferred from a condition type alone. A client must construct a condition only when its metadata has complete=true. The metadataProvider value identifies the extension supplying that guidance. Conditions without a provider remain visible with complete=false, but their data shape must be treated as unknown.

Condition value examples returned by this endpoint:

 ticketFinished:
 {"itemId":"<parallelTicketId>","ignoreIfNoLongerReachable":false}
 activityFinished:
 {"itemId":"<activityId>","ignoreIfNoLongerReachable":false}
 activityVisited:
 {"itemId":"<activityId>","ignoreIfNoLongerReachable":true}
 allTicketsFinished:
 null
 ticketHasValue:
 {"referencedTicket":null,"ticketFieldKey":"<fieldKey>",
  "operator":"<operatorFromThatField>","value":"<serializedValue>"}
 

For a request, the value is encoded in the native condition object. For example, the last value above becomes:

 {"type":"ticketHasValue",
  "conditionData":"{\"referencedTicket\":null,\"ticketFieldKey\":\"priority\",\"operator\":\"EQUALS\",\"value\":\"2\"}"}
 

Lists current process-editor metadata.

Action categories have exactly the semantics used by process validation: transition actions can be assigned to a transition, auto-transition actions can be executed without user interaction, activity actions can be allowed on an activity, parallel-closing actions close or delete a parallel ticket, and default activity actions are initially selected for a new activity. Ticket fields contain only operators supported by their actual field type.

Example: after reading this response, a client can construct an automatic transition as follows (using IDs and the operator returned in this response):

 {
   "actionid": 1234,
   "nextActivityId": "8a2f...",
   "conditionsForAutoTransition": [
     {"type": "activityFinished", "conditionData":
       "{\"itemId\":\"1b7c...\",\"ignoreIfNoLongerReachable\":false}"},
     {"type": "ticketHasValue", "conditionData":
       "{\"referencedTicket\":null,\"ticketFieldKey\":\"priority\",\"operator\":\"EQUALS\",\"value\":\"2\"}"}
   ]
 }
 

The condition data shape is available in ConditionMetadata#getValueType and ConditionMetadata#getExample. A null referencedTicket means the main ticket; a GUID selects a parallel ticket. The selected field's operator list defines valid values for operator. A ticketFinished condition requires a parallel ticket ID; activityFinished and activityVisited require an activity ID; allTicketsFinished has no data and is valid only for a main-ticket automatic transition when parallel tickets exist. The contexts value parallelTicketStart marks conditions accepted while starting a parallel ticket; such a condition must not refer to that same parallel ticket. Conditions in the same list are combined with AND. Before showing any condition editor, check complete; a false value means that the registered condition extension did not provide sufficient contexts, constraints, or an example.

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

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

{
    "transitionActions": [
        {
            "uid": "string",
            "internal": true,
            "statusId": 0,
            "displayName": "string",
            "id": 0
        }
    ],
    "ticketFields": [
        {
            "displayType": "string",
            "visibility": "string",
            "operators": [
                
            ],
            "displayName": "string",
            "fieldClass": "string"
        }
    ],
    "defaultActivityActions": [
        {
            "uid": "string",
            "internal": true,
            "statusId": 0,
            "displayName": "string",
            "id": 0
        }
    ],
    "parallelClosingActions": [
        {
            "uid": "string",
            "internal": true,
            "statusId": 0,
            "displayName": "string",
            "id": 0
        }
    ],
    "activityActions": [
        {
            "uid": "string",
            "internal": true,
            "statusId": 0,
            "displayName": "string",
            "id": 0
        }
    ]
}

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": "as8ph45fc03kiyabwvqqkejqc",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "1z0x258wqtfpymo66kfv61x2v",
            "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": "249nqw2sh155894qy28ig2nbc",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "1z0x258wqtfpymo66kfv61x2v",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

{
    "folderPath": "string",
    "id": "as8ph45fc03kiyabwvqqkejqc",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "1z0x258wqtfpymo66kfv61x2v",
            "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": "249nqw2sh155894qy28ig2nbc",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "1z0x258wqtfpymo66kfv61x2v",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

{
    "folderPath": "string",
    "id": "as8ph45fc03kiyabwvqqkejqc",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "1z0x258wqtfpymo66kfv61x2v",
            "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.