/api/helpdesk/processes/import

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.

Imports one native .process document. ConflictMode#FAIL rejects any global identifier conflict or same-folder name conflict, ConflictMode#COPY generates a new identifier and unique name, and ConflictMode#OVERWRITE updates the matching ID or same-folder name. The complete document is parsed and validated before writing. The JSON request part is {"folderId":"...","conflictMode":"COPY"} with media type application/json; the file part may use any name because this method has one upload parameter.

 curl -F 'json={"folderId":"folder-a","conflictMode":"OVERWRITE"};type=application/json' \\
      -F 'processFile=@incident.process' \\
      https://host/api/helpdesk/processes/import
 

# Request
curl --request POST '/api/helpdesk/processes/import' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <access-token>' \
  --form 'json={"conflictMode":"FAIL","folderId":"3ojm2s95si40gawda8ju52g62"};type=application/json' \
  --form 'processFile=@processFile.bin'

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

{
    "processId": "1rpyqio9ty3tmidz3ci44y0zn",
    "created": true,
    "overwritten": true
}

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": "c221ifjtspx0d9i2r5ejbj140",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7tse165d26knqy4sd20p2uonl",
            "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": "dgih1xlye9lswvfg7iufpo3x9",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7tse165d26knqy4sd20p2uonl",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

{
    "folderPath": "string",
    "id": "c221ifjtspx0d9i2r5ejbj140",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7tse165d26knqy4sd20p2uonl",
            "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": "dgih1xlye9lswvfg7iufpo3x9",
    "name": "string",
    "description": "string",
    "activities": [
        {
            "nextProcessToStart": "7tse165d26knqy4sd20p2uonl",
            "followUpActivities": [
                
            ],
            "ticketText": null,
            "mainTicketTextInParallelMode": "NONE",
            "name": "string"
        }
    ]
}

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

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