HelpDesk Processes
/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.
POST /api/helpdesk/processes/import
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 Body
| Content Type | Schema | Required | Description |
|---|---|---|---|
multipart/form-data |
object |
yes | Send JSON data in the 'json' part with application/json. A single file parameter accepts any part name; multiple file parameters use their documented names, and a file list receives the remaining file parts. |
Response
| Status | Content Type | Schema | Description |
|---|---|---|---|
200 |
application/json |
ImportResult |
import result containing resulting process ID and operation mode |
Example Request
# Request
curl --request POST '/api/helpdesk/processes/import' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <access-token>' \
--form 'json={"conflictMode":"FAIL","folderId":"629ipd00mref9yrn1imd0awmn"};type=application/json' \
--form 'processFile=@processFile.bin'
# Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"processId": "evfn5qvwqhf6687ygcc7i1of0",
"created": true,
"overwritten": true
}
DELETE /api/helpdesk/processes/{processId}
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.
Parameters
| Name | Location | Type | Required | Description |
|---|---|---|---|---|
processId |
path | string |
yes | process identifier from the URL |
Response
| Status | Content Type | Schema | Description |
|---|---|---|---|
204 |
— | — | No content. |
Example Request
# Request DELETE /api/helpdesk/processes/<processId> HTTP/1.1 Accept: application/json Authorization: Bearer <access-token> # Response HTTP/1.1 204 No Content
GET /api/helpdesk/processes/{processId}
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.
Parameters
| Name | Location | Type | Required | Description |
|---|---|---|---|---|
processId |
path | string |
yes | process identifier from the URL |
fields |
query | string |
no | Comma-separated readable properties to include in the JSON response. |
Response
| Status | Content Type | Schema | Description |
|---|---|---|---|
200 |
application/json |
ProcessRead |
Successful response. |
Example Request
# 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": "0mztnu1wj25v3qmchbtimhd0y",
"name": "string",
"description": "string",
"activities": [
{
"nextProcessToStart": "5ks2r3uk4tnangbugkhd8j9hl",
"followUpActivities": [
],
"ticketText": null,
"mainTicketTextInParallelMode": "NONE",
"name": "string"
}
]
}
PATCH /api/helpdesk/processes/{processId}
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.
Parameters
| Name | Location | Type | Required | Description |
|---|---|---|---|---|
processId |
path | string |
yes | process identifier from the URL |
Request Body
| Content Type | Schema | Required | Description |
|---|---|---|---|
application/json |
ProcessUpdate |
yes | — |
Response
| Status | Content Type | Schema | Description |
|---|---|---|---|
200 |
application/json |
ProcessRead |
Successful response. |
Example Request
# Request
PATCH /api/helpdesk/processes/<processId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json
{
"folderPath": "string",
"id": "ak75oxxskajcmqurlugl7g26s",
"name": "string",
"description": "string",
"activities": [
{
"nextProcessToStart": "5ks2r3uk4tnangbugkhd8j9hl",
"followUpActivities": [
],
"ticketText": null,
"mainTicketTextInParallelMode": "NONE",
"name": "string"
}
]
}
# Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"folderPath": "string",
"id": "0mztnu1wj25v3qmchbtimhd0y",
"name": "string",
"description": "string",
"activities": [
{
"nextProcessToStart": "5ks2r3uk4tnangbugkhd8j9hl",
"followUpActivities": [
],
"ticketText": null,
"mainTicketTextInParallelMode": "NONE",
"name": "string"
}
]
}
PUT /api/helpdesk/processes/{processId}
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.
Parameters
| Name | Location | Type | Required | Description |
|---|---|---|---|---|
processId |
path | string |
yes | process identifier from the URL |
Request Body
| Content Type | Schema | Required | Description |
|---|---|---|---|
application/json |
ProcessUpdate |
yes | — |
Response
| Status | Content Type | Schema | Description |
|---|---|---|---|
200 |
application/json |
ProcessRead |
Successful response. |
Example Request
# Request
PUT /api/helpdesk/processes/<processId> HTTP/1.1
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json
{
"folderPath": "string",
"id": "ak75oxxskajcmqurlugl7g26s",
"name": "string",
"description": "string",
"activities": [
{
"nextProcessToStart": "5ks2r3uk4tnangbugkhd8j9hl",
"followUpActivities": [
],
"ticketText": null,
"mainTicketTextInParallelMode": "NONE",
"name": "string"
}
]
}
# Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"folderPath": "string",
"id": "0mztnu1wj25v3qmchbtimhd0y",
"name": "string",
"description": "string",
"activities": [
{
"nextProcessToStart": "5ks2r3uk4tnangbugkhd8j9hl",
"followUpActivities": [
],
"ticketText": null,
"mainTicketTextInParallelMode": "NONE",
"name": "string"
}
]
}
Common Error Responses
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": []
}
Schemas
Request and response schemas used on this page.
ImportRequest
| Property | Type | Required | Description |
|---|---|---|---|
conflictMode |
string [FAIL, COPY, OVERWRITE] |
no | — |
folderId |
string |
no | — |
ImportResult
| Property | Type | Required | Description |
|---|---|---|---|
processId |
string |
no | — |
created |
boolean |
no | — |
overwritten |
boolean |
no | — |
ApiError
| Property | Type | Required | Description |
|---|---|---|---|
status |
integer (int32) |
yes | — |
code |
string |
yes | — |
message |
string |
yes | — |
details |
array<object> |
no | — |
ProcessRead
| Property | Type | Required | Description |
|---|---|---|---|
folderPath |
string |
no |
Human-readable folder path, or an empty string for the root folder. |
id |
string |
no |
Stable process identifier. Read-only on the model endpoint; the URL identifier is the target of PUT and PATCH updates. A value supplied in an update body is accepted for GET-to-PUT/PATCH round-trips and ignored; the URL identifier remains authoritative. Native |
name |
string |
no |
Required process name, unique case-insensitively within its folder. |
description |
string |
no |
Optional process description. A null value removes the description. |
activities |
array<Activity> |
no |
Complete main-ticket activity graph, including transition condition data. PUT and PATCH replace this collection completely; omitted requests retain the current graph. |
startActivityId |
string |
no |
Identifier of the activity where the main ticket starts. An explicit |
parallelTickets |
array<ParallelTicket> |
no |
Complete parallel-ticket definitions, including their start conditions. PUT and PATCH replace this collection completely; omitted requests retain the current definitions. |
autoResourceAccess |
string [NONE, READ, WRITE] |
no |
Access level automatically granted to participating resources. |
canBeChangedWhenActive |
boolean |
no |
Whether a running process may use this definition after it has been changed. |
folderId |
string |
no |
Stable identifier of folder containing this process, including root folder. This property is not part of the native |
Activity
| Property | Type | Required | Description |
|---|---|---|---|
nextProcessToStart |
string |
no | — |
followUpActivities |
array<ActivityTransition> |
no | — |
ticketText |
ReaStepTextVO |
no | — |
mainTicketTextInParallelMode |
string [NONE, APPEND, PREPEND] |
no | — |
name |
string |
no | — |
allowedActions |
array<integer (int32)> |
no | — |
description |
string |
no | — |
weight |
integer (int32) |
no | — |
processTicketData |
ProcessTicketData |
no | — |
id |
string |
no | — |
type |
string [Standard, FinishProcess] |
no | — |
requiredFieldKeys |
array<string> |
no | — |
ActivityTransition
| Property | Type | Required | Description |
|---|---|---|---|
actionid |
integer (int32) |
no | — |
autoTransitionText |
ReaStepTextVO |
no | — |
conditionsForAutoTransition |
array<ProcessCondition> |
no | — |
nextActivityId |
string |
no | — |
actionLabel |
string |
no | — |
ReaStepTextVO
| Property | Type | Required | Description |
|---|---|---|---|
duplicatedContent |
array<DuplicateRange> |
no | — |
text |
string |
no | — |
htmlContent |
boolean |
no | — |
DuplicateRange
| Property | Type | Required | Description |
|---|---|---|---|
uid |
string |
no | — |
ids |
array<integer (int32)> |
no | — |
from |
integer (int32) |
no | — |
to |
integer (int32) |
no | — |
ProcessCondition
| Property | Type | Required | Description |
|---|---|---|---|
conditionData |
string |
no | — |
type |
string |
no | — |
ProcessTicketData
| Property | Type | Required | Description |
|---|---|---|---|
map |
object |
no | — |
ProcessValueReference
| Property | Type | Required | Description |
|---|---|---|---|
field |
string |
no | — |
valueString |
string |
no | — |
referenceType |
integer (int32) |
no | — |
parallelTicketId |
string |
no | — |
ParallelTicket
| Property | Type | Required | Description |
|---|---|---|---|
startActivityId |
string |
no | — |
startCondition |
array<ProcessCondition> |
no | — |
actionOnMainTicketEnd |
integer (int32) |
no | — |
activities |
array<Activity> |
no | — |
name |
string |
no | — |
id |
string |
no | — |
relativeLatestStart |
number (int64) |
no | — |
deactivated |
boolean |
no | — |
ProcessUpdate
| Property | Type | Required | Description |
|---|---|---|---|
folderPath |
string |
no |
Accepts the computed folder path emitted by GET responses for round-trip updates. Folder placement is controlled by |
id |
string |
no |
Accepts the read-only identifier emitted by GET responses so a resource can be sent back unchanged. The URL remains authoritative and the supplied value is intentionally ignored. |
name |
string |
no |
Required process name, unique case-insensitively within its folder. |
description |
string |
no |
Optional process description. A null value removes the description. |
activities |
array<Activity> |
no |
Complete main-ticket activity graph, including transition condition data. PUT and PATCH replace this collection completely; omitted requests retain the current graph. |
startActivityId |
string |
no |
Identifier of the activity where the main ticket starts. An explicit |
parallelTickets |
array<ParallelTicket> |
no |
Complete parallel-ticket definitions, including their start conditions. PUT and PATCH replace this collection completely; omitted requests retain the current definitions. |
autoResourceAccess |
string [NONE, READ, WRITE] |
no |
Access level automatically granted to participating resources. |
canBeChangedWhenActive |
boolean |
no |
Whether a running process may use this definition after it has been changed. |
folderId |
string |
no |
Stable identifier of folder containing this process, including root folder. This property is not part of the native |