diff --git a/images/system/core-workflows/add-new-workflow.png b/images/system/core-workflows/add-new-workflow.png deleted file mode 100644 index 0d9310c6..00000000 Binary files a/images/system/core-workflows/add-new-workflow.png and /dev/null differ diff --git a/images/system/core-workflows/examples/1_group-specific-fields-and-values_result.gif b/images/system/core-workflows/examples/1_group-specific-fields-and-values_result.gif deleted file mode 100644 index d3200f4f..00000000 Binary files a/images/system/core-workflows/examples/1_group-specific-fields-and-values_result.gif and /dev/null differ diff --git a/images/system/core-workflows/examples/1_group-specific-fields-and-values_sales.png b/images/system/core-workflows/examples/1_group-specific-fields-and-values_sales.png deleted file mode 100644 index f5a95536..00000000 Binary files a/images/system/core-workflows/examples/1_group-specific-fields-and-values_sales.png and /dev/null differ diff --git a/images/system/core-workflows/examples/1_group-specific-fields-and-values_support.png b/images/system/core-workflows/examples/1_group-specific-fields-and-values_support.png deleted file mode 100644 index 7198cbb7..00000000 Binary files a/images/system/core-workflows/examples/1_group-specific-fields-and-values_support.png and /dev/null differ diff --git a/images/system/core-workflows/examples/2_role-specific-approval-settingsl_result.gif b/images/system/core-workflows/examples/2_role-specific-approval-settingsl_result.gif deleted file mode 100644 index bf769e4d..00000000 Binary files a/images/system/core-workflows/examples/2_role-specific-approval-settingsl_result.gif and /dev/null differ diff --git a/images/system/core-workflows/examples/3_state-dependent-mandatory-fields_result.gif b/images/system/core-workflows/examples/3_state-dependent-mandatory-fields_result.gif deleted file mode 100644 index a1cc221d..00000000 Binary files a/images/system/core-workflows/examples/3_state-dependent-mandatory-fields_result.gif and /dev/null differ diff --git a/locale/admin-docs.pot b/locale/admin-docs.pot index 2ffe3549..20125592 100644 --- a/locale/admin-docs.pot +++ b/locale/admin-docs.pot @@ -250,6 +250,11 @@ msgstr "" #: ../channels/chat.rst:28 #: ../channels/microsoft365-graph/accounts.rst:23 #: ../misc/first-steps.rst:20 +#: ../system/core-workflows/learn-by-example.rst:36 +#: ../system/core-workflows/learn-by-example.rst:91 +#: ../system/core-workflows/learn-by-example.rst:139 +#: ../system/core-workflows/learn-by-example.rst:199 +#: ../system/core-workflows/learn-by-example.rst:238 #: ../system/integrations/clearbit.rst:35 msgid "Configuration" msgstr "" @@ -1223,6 +1228,11 @@ msgstr "" #: ../manage/scheduler.rst:155 #: ../manage/webhook/add.rst:116 #: ../misc/variables.rst:104 +#: ../system/core-workflows/learn-by-example.rst:37 +#: ../system/core-workflows/learn-by-example.rst:92 +#: ../system/core-workflows/learn-by-example.rst:140 +#: ../system/core-workflows/learn-by-example.rst:200 +#: ../system/core-workflows/learn-by-example.rst:239 #: ../system/integrations/cti/includes/inbound-calls.include.rst:15 #: ../system/integrations/cti/includes/outbound-calls.include.rst:18 #: ../system/integrations/cti/includes/inbound-calls.include.rst:14 @@ -6390,8 +6400,8 @@ msgstr "" #: ../manage/trigger.rst:32 #: ../manage/webhook.rst:45 #: ../manage/webhook.rst:45 -#: ../system/core-workflows.rst:28 -#: ../system/core-workflows.rst:28 +#: ../system/core-workflows.rst:23 +#: ../system/core-workflows.rst:23 #: ../system/objects.rst:32 #: ../system/objects.rst:32 msgid "Learn more" @@ -7746,7 +7756,12 @@ msgstr "" #: ../manage/public-links.rst:79 #: ../misc/object-conditions/basics.rst:62 -#: ../system/core-workflows/how-do-they-work.rst:23 +#: ../system/core-workflows/how-do-they-work.rst:14 +#: ../system/core-workflows/learn-by-example.rst:43 +#: ../system/core-workflows/learn-by-example.rst:98 +#: ../system/core-workflows/learn-by-example.rst:146 +#: ../system/core-workflows/learn-by-example.rst:206 +#: ../system/core-workflows/learn-by-example.rst:245 msgid "Context" msgstr "" @@ -9095,6 +9110,7 @@ msgid "Scheduler jobs can process a maximum of ``2000`` objects per run. This is msgstr "" #: ../manage/scheduler.rst:22 +#: ../system/core-workflows/learn-by-example.rst:8 msgid "Basics" msgstr "" @@ -9175,7 +9191,12 @@ msgid "Choose the points in time when the scheduler should run. It depends on th msgstr "" #: ../manage/scheduler.rst:94 -#: ../system/core-workflows/how-do-they-work.rst:15 +#: ../system/core-workflows/how-do-they-work.rst:7 +#: ../system/core-workflows/learn-by-example.rst:39 +#: ../system/core-workflows/learn-by-example.rst:94 +#: ../system/core-workflows/learn-by-example.rst:142 +#: ../system/core-workflows/learn-by-example.rst:202 +#: ../system/core-workflows/learn-by-example.rst:241 msgid "Object" msgstr "" @@ -9501,17 +9522,14 @@ msgid "**Groups**" msgstr "" #: ../manage/slas/learn-by-example.rst:18 -#: ../system/core-workflows/learn-by-example.rst:16 msgid "Sales" msgstr "" #: ../manage/slas/learn-by-example.rst:19 -#: ../system/core-workflows/learn-by-example.rst:17 msgid "Support" msgstr "" #: ../manage/slas/learn-by-example.rst:20 -#: ../system/core-workflows/learn-by-example.rst:18 msgid "2nd Level" msgstr "" @@ -9581,8 +9599,6 @@ msgstr "" #: ../manage/slas/learn-by-example.rst:86 #: ../manage/slas/learn-by-example.rst:116 -#: ../system/core-workflows/learn-by-example.rst:89 -#: ../system/core-workflows/learn-by-example.rst:102 msgid "The result" msgstr "" @@ -10153,6 +10169,11 @@ msgstr "" #: ../misc/object-conditions/basics.rst:191 #: ../misc/variables/ticket.rst:2 #: ../settings/ticket.rst:2 +#: ../system/core-workflows/learn-by-example.rst:40 +#: ../system/core-workflows/learn-by-example.rst:95 +#: ../system/core-workflows/learn-by-example.rst:143 +#: ../system/core-workflows/learn-by-example.rst:203 +#: ../system/core-workflows/learn-by-example.rst:242 msgid "Ticket" msgstr "" @@ -10280,7 +10301,12 @@ msgstr "" #: ../manage/trigger/how-do-they-work.rst:24 #: ../manage/webhook/examples/generic-notifications-trigger.rst:32 #: ../misc/object-conditions/basics.rst:66 -#: ../system/core-workflows/how-do-they-work.rst:70 +#: ../system/core-workflows/how-do-they-work.rst:60 +#: ../system/core-workflows/learn-by-example.rst:58 +#: ../system/core-workflows/learn-by-example.rst:113 +#: ../system/core-workflows/learn-by-example.rst:157 +#: ../system/core-workflows/learn-by-example.rst:223 +#: ../system/core-workflows/learn-by-example.rst:260 #: ../system/sessions.rst:51 msgid "Action" msgstr "" @@ -10336,7 +10362,7 @@ msgid "When creating a trigger, choose activator here:" msgstr "" #: ../manage/trigger/how-do-they-work.rst:64 -#: ../system/core-workflows/how-do-they-work.rst:37 +#: ../system/core-workflows/how-do-they-work.rst:28 msgid "Conditions" msgstr "" @@ -18208,27 +18234,27 @@ msgid "Core Workflows" msgstr "" #: ../system/core-workflows.rst:4 -msgid "Core Workflows allow you to adjust object attributes in many ways. For example:" +msgid "Core workflows allow you to adjust object attributes in many ways. For example:" msgstr "" #: ../system/core-workflows.rst:7 -msgid "Show / hide fields" +msgid "Show and hide fields" msgstr "" #: ../system/core-workflows.rst:8 -msgid "Adjust mandatory setting" +msgid "Adjust if fields are mandatory or not" msgstr "" #: ../system/core-workflows.rst:9 -msgid "Manipulate available options" +msgid "Set available options for select fields" msgstr "" #: ../system/core-workflows.rst:11 -msgid "With this, you can provide exactly the information your users really need!" +msgid "This allows you to provide exactly the information that your users really need." msgstr "" #: ../system/core-workflows.rst:15 -msgid "If the pre-defined :doc:`/system/objects` are not enough, please add custom object attributes first." +msgid "If the pre-defined :doc:`object attributes` are not enough, please add custom object attributes first." msgstr "" #: ../system/core-workflows.rst:17 @@ -18239,10 +18265,6 @@ msgstr "" msgid "This is a very enhanced functionality and can cause unexpected UI behavior. Please ensure to test your use cases after configuration to reduce surprises." msgstr "" -#: ../system/core-workflows.rst:None -msgid "Dialogue for adding a new workflow" -msgstr "" - #: ../system/core-workflows/condition-operators.rst:2 msgid "Core Workflow Condition Operators" msgstr "" @@ -18494,110 +18516,96 @@ msgid "How do they work?" msgstr "" #: ../system/core-workflows/how-do-they-work.rst:4 -msgid "Core Workflows are executed according to their priority. If two workflows have the same priority, they are executed in alphabetical order based on their **name**." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:8 -msgid "Because of the way Core Workflows work, all changes to attributes are checked with the application server - please see :doc:`limitations` for possible issues." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:12 -msgid "Below we're talking about settings that are important and not self-explanatory." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:17 -msgid "Choose the object context you want to run the workflow in. This will decide on your available attributes and actions." +msgid "Find a description of the different parts of the core workflows below." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:20 -msgid "Ticket objects also have access to the ticket customer." +#: ../system/core-workflows/how-do-they-work.rst:9 +msgid "Choose the object context you want to run the workflow in. This will decide on your available attributes and actions. Ticket objects also have access to the ticket customer." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:25 +#: ../system/core-workflows/how-do-they-work.rst:16 msgid "Choose in which situation the workflow is applied. Contexts can be combined to avoid duplicate workflows." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:30 +#: ../system/core-workflows/how-do-they-work.rst:21 +#: ../system/core-workflows/learn-by-example.rst:44 +#: ../system/core-workflows/learn-by-example.rst:99 +#: ../system/core-workflows/learn-by-example.rst:147 +#: ../system/core-workflows/learn-by-example.rst:207 +#: ../system/core-workflows/learn-by-example.rst:246 msgid "Creation mask" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:29 +#: ../system/core-workflows/how-do-they-work.rst:20 msgid "If selected, your conditions and actions will affect all applicable creation masks." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:34 +#: ../system/core-workflows/how-do-they-work.rst:25 +#: ../system/core-workflows/learn-by-example.rst:45 +#: ../system/core-workflows/learn-by-example.rst:100 +#: ../system/core-workflows/learn-by-example.rst:148 +#: ../system/core-workflows/learn-by-example.rst:208 +#: ../system/core-workflows/learn-by-example.rst:247 msgid "Edit mask" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:33 +#: ../system/core-workflows/how-do-they-work.rst:24 msgid "If selected, your conditions and actions will affect all applicable edit masks." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:39 -msgid "Zammad differentiates between selected and saved conditions. These can be combined wherever needed." +#: ../system/core-workflows/how-do-they-work.rst:30 +msgid "Zammad differentiates between selected and saved conditions. These can be combined wherever needed. You can find a description of the condition operators for core workflows in :doc:`/system/core-workflows/condition-operators`." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:42 +#: ../system/core-workflows/how-do-they-work.rst:35 msgid "**⚠️ Restrict workflows to specific roles if needed!**" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:44 +#: ../system/core-workflows/how-do-they-work.rst:37 msgid "By default and unless configured in conditions, workflow rules are executed for **all roles**. This also affects your customers!" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:50 +#: ../system/core-workflows/how-do-they-work.rst:43 msgid "Selected Conditions" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:48 +#: ../system/core-workflows/how-do-they-work.rst:41 msgid "These conditions are based on form values and match if an appropriate selection is made (e.g. choosing another group in the ticket without saving). This applies for drafts (active selection) and currently saved values." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:64 +#: ../system/core-workflows/how-do-they-work.rst:57 msgid "Saved Conditions" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:53 +#: ../system/core-workflows/how-do-they-work.rst:46 msgid "These conditions only match if the selected values are stored in the database. It ignores the current value or selection of the field, as long as the changes are not saved (e.g. performing field operations for an existing ticket, which is viewed/opened by an agent)." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:60 +#: ../system/core-workflows/how-do-they-work.rst:53 msgid "Keep in mind that the value has to be available in the situation where you need it. Otherwise the condition won't match." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:63 +#: ../system/core-workflows/how-do-they-work.rst:56 msgid "Example: you can't perform any actions with *saved condition* on a ticket in creation, because there are no saved values at that time." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:66 -msgid "You can find a description of the condition operators for core workflows :doc:`here `." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:72 -msgid "Which actions should we run on the relevant fields? The possible actions depend on the object type. However, usually you can at least change the visibility and whether the field is mandatory." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:76 -msgid "Be aware that actions are not available for **related** context." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:78 -msgid "**Example:** Let's assume you are working in the ticket context. While you can have customer *conditions*, you *can't adjust* objects with actions in that scope. That's because this wouldn't have any impact on the ticket dialog. Of course all ticket attributes (state, owner, ...) are available." +#: ../system/core-workflows/how-do-they-work.rst:62 +msgid "Define which actions should get applied to the relevant fields. The possible actions depend on the object type. However, usually you can at least change the visibility and whether the field is mandatory." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:84 -msgid "Please also have a look at our :doc:`limitations` to be safe from surprises." +#: ../system/core-workflows/how-do-they-work.rst:66 +msgid "Be aware that actions are not available for **related** context. Example: Let's assume you are working in the ticket context. While you can have customer *conditions*, you *can't adjust* objects with actions in that scope. That's because this wouldn't have any impact on the ticket dialog. Of course all ticket attributes (state, owner, ...) are available." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:88 +#: ../system/core-workflows/how-do-they-work.rst:74 msgid "Available Operators" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:90 +#: ../system/core-workflows/how-do-they-work.rst:76 msgid "The availability of operators depends on the object type and scope." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:94 +#: ../system/core-workflows/how-do-they-work.rst:80 msgid "Please note that actions may or may not restrict API based access to attributes. We're displaying the following icons for your overview to understand these limits better:" msgstr "" @@ -18605,13 +18613,13 @@ msgstr "" msgid "|api| This icon indicates the action affects the API." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 -#: ../system/core-workflows/how-do-they-work.rst:163 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:149 msgid "api" msgstr "" @@ -18619,183 +18627,179 @@ msgstr "" msgid "|ui| This icon indicates the action only affects the web interface." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 -#: ../system/core-workflows/how-do-they-work.rst:167 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:153 msgid "ui" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:102 +#: ../system/core-workflows/how-do-they-work.rst:88 msgid "show |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:102 +#: ../system/core-workflows/how-do-they-work.rst:88 msgid "Display the chosen field. Allows setting of values." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:109 +#: ../system/core-workflows/how-do-they-work.rst:95 msgid "hide |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:105 +#: ../system/core-workflows/how-do-they-work.rst:91 msgid "Hide the chosen field. However, it technically still allows setting the field." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:108 +#: ../system/core-workflows/how-do-they-work.rst:94 msgid "Please note that the field is **not** gone and still contains an existing value (if set)! Consider *remove* instead, if you want this field to be gone." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:112 +#: ../system/core-workflows/how-do-they-work.rst:98 msgid "remove |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:112 +#: ../system/core-workflows/how-do-they-work.rst:98 msgid "Entirely removes the field. The field value will not be evaluated." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:115 +#: ../system/core-workflows/how-do-they-work.rst:101 msgid "set mandatory |ui| |api|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:115 +#: ../system/core-workflows/how-do-they-work.rst:101 msgid "Sets the field to mandatory." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:118 +#: ../system/core-workflows/how-do-they-work.rst:104 msgid "set optional |ui| |api|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:118 +#: ../system/core-workflows/how-do-they-work.rst:104 msgid "Sets the field to optional." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:124 +#: ../system/core-workflows/how-do-they-work.rst:110 msgid "add option |ui| |api|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:121 +#: ../system/core-workflows/how-do-they-work.rst:107 msgid "Allows adding options to tree selects or selects." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:123 +#: ../system/core-workflows/how-do-they-work.rst:109 msgid "You have to use the \"remove option\" before performing this action. It allows you to use *existing* configured values." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:128 +#: ../system/core-workflows/how-do-they-work.rst:114 msgid "remove option |ui| |api|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:127 +#: ../system/core-workflows/how-do-they-work.rst:113 msgid "Allows removing options from tree selects or selects. It allows you to use *existing* configured values." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:134 +#: ../system/core-workflows/how-do-they-work.rst:120 msgid "set fixed to |ui| |api|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:131 +#: ../system/core-workflows/how-do-they-work.rst:117 msgid "Reduces the available options by your selection." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:133 +#: ../system/core-workflows/how-do-they-work.rst:119 msgid "This reduces your workflows in terms of *add option* and *remove option*." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:137 +#: ../system/core-workflows/how-do-they-work.rst:123 msgid "fill in |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:137 +#: ../system/core-workflows/how-do-they-work.rst:123 msgid "Allows filling in of string and integer fields with your values." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:141 +#: ../system/core-workflows/how-do-they-work.rst:127 msgid "fill in empty |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:140 +#: ../system/core-workflows/how-do-they-work.rst:126 msgid "Allows filling in of string and integer fields with your values **if the field is empty**." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:144 +#: ../system/core-workflows/how-do-they-work.rst:130 msgid "select |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:144 +#: ../system/core-workflows/how-do-they-work.rst:130 msgid "Select a specific value within a select, tree select or boolean field." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:153 +#: ../system/core-workflows/how-do-they-work.rst:139 msgid "auto select |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:147 +#: ../system/core-workflows/how-do-they-work.rst:133 msgid "Helps users with tree select and select fields:" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:149 +#: ../system/core-workflows/how-do-they-work.rst:135 msgid "If the field has only one option available for selection and no value yet, the value will be automatically set." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:152 +#: ../system/core-workflows/how-do-they-work.rst:138 msgid "This option only works if you have one value and doesn't work if there is more than one option available." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:157 +#: ../system/core-workflows/how-do-they-work.rst:143 msgid "set readonly |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:156 +#: ../system/core-workflows/how-do-they-work.rst:142 msgid "Allows you to display an attribute as read only (which means no changes are possible)." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:161 +#: ../system/core-workflows/how-do-they-work.rst:147 msgid "unset readonly |ui|" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:160 +#: ../system/core-workflows/how-do-they-work.rst:146 msgid "In case a workflow set the field in question to read only, you can undo this with option above." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:172 +#: ../system/core-workflows/how-do-they-work.rst:158 msgid "Stop after match" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:174 -msgid "Here you can decide if other workflows are executed after the current one." -msgstr "" - -#: ../system/core-workflows/how-do-they-work.rst:176 -msgid "If set to ``no`` (default), further workflows will be executed if they match the condition. In this case, it is possible that your actions from the current workflow can be overwritten by another workflow." +#: ../system/core-workflows/how-do-they-work.rst:160 +msgid "Decide if other workflows are executed after the current one." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:180 -msgid "If set to ``yes``, no further workflows will be executed after the current one." +#: ../system/core-workflows/how-do-they-work.rst:162 +msgid "If set to ``no`` (default), further workflows will be executed if they match the condition. In this case, it is possible that your actions from the current workflow can be overwritten by another workflow. If set to ``yes``, no further workflows will be executed after the current one." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:184 +#: ../system/core-workflows/how-do-they-work.rst:169 msgid "Priority" msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:186 -msgid "You can define the sequence, in which the workflows are executed. The default value is ``500``." +#: ../system/core-workflows/how-do-they-work.rst:171 +msgid "You can define the sequence of execution of the workflows by settings a numeric value. The execution runs in ascending order. That means lower values (e.g. ``100``) are executed before higher ones (e.g. ``999``)." msgstr "" -#: ../system/core-workflows/how-do-they-work.rst:189 -msgid "The workflows are executed in ascending order by their priority. That means lower values (e.g. ``100``) are executed before higher ones (e.g. ``999``)." +#: ../system/core-workflows/how-do-they-work.rst:175 +msgid "The default value is ``500``." msgstr "" #: ../system/core-workflows/learn-by-example.rst:2 @@ -18803,272 +18807,366 @@ msgid "Learn by Example" msgstr "" #: ../system/core-workflows/learn-by-example.rst:4 -msgid "This page provides some basic examples for Core Workflows. Of course you can build much more complex workflows if needed. To learn about Core Workflows in detail, first go to :doc:`how-do-they-work`." +msgid "This page showcases some examples for core workflows. To learn about core workflows in detail, first go to :doc:`how-do-they-work`." +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:10 +msgid "All core workflow examples below are configured in the same system. Compared to a fresh installation of Zammad, the system has some additional groups and some custom object attributes you can find in the respective examples. See these examples as inspiration and adapt the workflows to your processes." +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:16 +msgid "Group Based Fields" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:18 +msgid "Often, different teams (like sales, support, or 2nd level) need slightly different workflows to handle tickets effectively. Group-based workflows allow you to customize the ticket experience by defining the fields displayed, the required input and the available options based on the group assigned to the ticket." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:9 -msgid "Group Based Examples" +#: ../system/core-workflows/learn-by-example.rst:28 +#: ../system/core-workflows/learn-by-example.rst:83 +#: ../system/core-workflows/learn-by-example.rst:131 +#: ../system/core-workflows/learn-by-example.rst:184 +msgid "Problem/scenario" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:11 -msgid "All following workflows have the same base configurations. The workflow may not use them all." +#: ../system/core-workflows/learn-by-example.rst:25 +msgid "When a ticket is created in or moved to the ``2nd Level`` group, the category field must be limited, some fields have to be shown and specific fields are mandatory to have all relevant information for the 2nd level support present in the ticket." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:14 -msgid "Groups:" +#: ../system/core-workflows/learn-by-example.rst:63 +#: ../system/core-workflows/learn-by-example.rst:115 +#: ../system/core-workflows/learn-by-example.rst:159 +#: ../system/core-workflows/learn-by-example.rst:273 +msgid "Workflow configuration" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:19 -msgid "Attributes:" +#: ../system/core-workflows/learn-by-example.rst:35 +#: ../system/core-workflows/learn-by-example.rst:90 +#: ../system/core-workflows/learn-by-example.rst:138 +#: ../system/core-workflows/learn-by-example.rst:198 +#: ../system/core-workflows/learn-by-example.rst:237 +msgid "Area" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:21 -msgid "Category (Single tree selection field, not mandatory, agents only)" +#: ../system/core-workflows/learn-by-example.rst:48 +#: ../system/core-workflows/learn-by-example.rst:103 +#: ../system/core-workflows/learn-by-example.rst:151 +#: ../system/core-workflows/learn-by-example.rst:211 +#: ../system/core-workflows/learn-by-example.rst:250 +msgid "Selected conditions" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:22 -msgid "Approved (Boolean field, not mandatory, not shown, ``false`` as default)" +#: ../system/core-workflows/learn-by-example.rst:49 +msgid "**Group** *is* ``2nd Level``" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:23 -msgid "Operating System (Text field, not mandatory, not shown)" +#: ../system/core-workflows/learn-by-example.rst:52 +#: ../system/core-workflows/learn-by-example.rst:109 +#: ../system/core-workflows/learn-by-example.rst:217 +#: ../system/core-workflows/learn-by-example.rst:256 +msgid "Saved conditions" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:24 -msgid "Software used (Single selection field, not mandatory, not shown)" +#: ../system/core-workflows/learn-by-example.rst:54 +msgid "Not used because the UI has to change" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:67 -msgid "Group specific values and fields" +#: ../system/core-workflows/learn-by-example.rst:56 +msgid "immediately when the group is set to 2nd Level." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:27 -msgid "This workflow set depends on the category field. It reduces the available set of values based on the group selected." +#: ../system/core-workflows/learn-by-example.rst:59 +msgid "**Category** *show*" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:32 -msgid "Workflow 2nd Level group" +#: ../system/core-workflows/learn-by-example.rst:60 +msgid "**Category** *set fixed to* ``2nd Level`` (and all sub categories)" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:34 -msgid "This reduces the category options to ``2nd Level/*``, ``Internal/*`` and ``Others``. It also sets further required fields to mandatory and visible." +#: ../system/core-workflows/learn-by-example.rst:61 +msgid "**Operating System** and **Software used** *show*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:62 +msgid "**Operating System** and **Software used** *set mandatory*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:68 +#: ../system/core-workflows/learn-by-example.rst:120 +#: ../system/core-workflows/learn-by-example.rst:165 +#: ../system/core-workflows/learn-by-example.rst:296 +msgid "Configuration in UI" msgstr "" #: ../system/core-workflows/learn-by-example.rst:0 msgid "Sample workflow that shows specific values and fields for 2nd level" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:42 -msgid "Workflow Support group" +#: ../system/core-workflows/learn-by-example.rst:71 +msgid "Approval Process" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:44 -msgid "This reduces the category options to ``Support/*``, ``Internal/*`` and ``Others``. It also sets further required fields to visible." +#: ../system/core-workflows/learn-by-example.rst:73 +msgid "In many organizations, an approval is required to initiate subsequent processes. This approval is usually limited to a specific group of people to ensure that all requirements for the subsequent process are fulfilled." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Sample workflow that shows specific values and fields for support" +#: ../system/core-workflows/learn-by-example.rst:78 +msgid "The approval of a customer issue can only be done by users with the role ``Approval Person``. As long as this approval has not been done, the value must be set fixed to ``no``, unless the approval person views the ticket." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:52 -msgid "Workflow Sales group" +#: ../system/core-workflows/learn-by-example.rst:82 +msgid "Based on the approval state, additional automation processes can be established (e.g. a trigger to raise the priority or assign a specific agent)." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:54 -msgid "This reduces the category options to ``Sales/*``, ``Internal/*`` and ``Others``." +#: ../system/core-workflows/learn-by-example.rst:104 +msgid "**Role** *is not* ``Approval Person``" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Sample workflow that shows specific values and fields for sales" +#: ../system/core-workflows/learn-by-example.rst:105 +msgid "Checks if role is not ``Approval Person`` for unsaved" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:67 -#: ../system/integrations/slack.rst:88 -msgid "The Result" +#: ../system/core-workflows/learn-by-example.rst:107 +msgid "changes in the ticket." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:62 -msgid "This is what the agent would experience with the above workflows in place." +#: ../system/core-workflows/learn-by-example.rst:110 +msgid "**Approved** *is not* ``yes``" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Workflow shows objects and limits options based on selections on the group" +#: ../system/core-workflows/learn-by-example.rst:111 +msgid "Checks if the approval is not yet set to ``yes``." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:89 -msgid "Approval process" +#: ../system/core-workflows/learn-by-example.rst:114 +msgid "**Approved** *set fixed to* ``no``" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:70 -msgid "In this case ``approved`` is visible to agents by default. For this workflow, an additional role ``Approval person`` is required (no further permissions)." +#: ../system/core-workflows/learn-by-example.rst:115 +msgid "Prevents changes when above conditions are met." msgstr "" #: ../system/core-workflows/learn-by-example.rst:0 msgid "Sample workflow that restricts an approval attribute to specific roles" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:80 -msgid "This workflow may work best in combination with a :doc:`trigger ` but technically, this is not required." +#: ../system/core-workflows/learn-by-example.rst:123 +msgid "Enforcing Ticket Categorization" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:83 -msgid "Select fields may be a better approach because they allow more values than just a simple ``true`` or ``false``." +#: ../system/core-workflows/learn-by-example.rst:125 +msgid "To have convincing numbers for your statistic, it can be a good idea to enforce certain attributes to be populated before the ticket can be closed." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Workflow fixes possible values of \"Approved ?\" to a specific selection depending on the users role" +#: ../system/core-workflows/learn-by-example.rst:129 +msgid "The ``Category`` field must be set to mandatory if an agent wants to set the states ``closed`` or ``pending close`` to enforce categorization." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:102 -msgid "State dependent mandatory fields" +#: ../system/core-workflows/learn-by-example.rst:152 +msgid "**State** *is* ``closed`` or ``pending close``" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:92 -msgid "This workflow sets ``Category`` to mandatory if the agent wants to set the states ``closed`` or ``pending close`` to enforce categorization." +#: ../system/core-workflows/learn-by-example.rst:153 +#: ../system/core-workflows/learn-by-example.rst:252 +msgid "Selected condition because it has to be" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:155 +#: ../system/core-workflows/learn-by-example.rst:254 +msgid "checked before changes are saved." +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:158 +msgid "**Category** *set mandatory*" msgstr "" #: ../system/core-workflows/learn-by-example.rst:0 msgid "Sample workflow that sets fields to mandatory on specific states" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Workflow sets category field to mandatory upon choosing closed or pending close as state" +#: ../system/core-workflows/learn-by-example.rst:168 +msgid "Ticket Handover Process" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:105 -msgid "Manual Ticket Handover Process" +#: ../system/core-workflows/learn-by-example.rst:170 +msgid "A handover from one agent to another might require more than just a change of the owner. Depending on the issue or process, it can be very helpful that the original agent leaves a small note so the new agent knows immediately what's the reason for the handover and where to start." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:107 -msgid "This example covers the handover of a ticket from one agent to another:" +#: ../system/core-workflows/learn-by-example.rst:176 +msgid "Agents must write a small comment when they want to change the ticket owner. There is a custom ticket attribute called ``Handover`` where a text can be inserted. This field is hidden by default (Workflow 1) and only shows up when the owner changes. Additionally, it must be set to mandatory in such a case (Workflow 2)." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:109 -msgid "When the ticket owner is modified, a new text field (\"Handover\") shows up for a comment" +#: ../system/core-workflows/learn-by-example.rst:182 +msgid "Because the field is hidden after saving the change of the ticket owner, the text of the field has to be written to the ticket as an article by a trigger. Otherwise, the new agent would not see it at all." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:111 -msgid "This may only be visible when the owner is changed, therefore it has to be hidden in general" +#: ../system/core-workflows/learn-by-example.rst:189 +#: ../system/core-workflows/learn-by-example.rst:278 +msgid "Workflow 1" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:113 -msgid "The input in this handover text field is mandatory" +#: ../system/core-workflows/learn-by-example.rst:191 +msgid "This workflow hides the field in general. Please note the lower priority which tells Zammad to execute this workflow first." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:114 -msgid "After submitting changes, the value of the handover field must be added as an note to the ticket (via trigger)" +#: ../system/core-workflows/learn-by-example.rst:213 +#: ../system/core-workflows/learn-by-example.rst:219 +msgid "No condition needed, because it should" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:120 -msgid "Hiding handover field" +#: ../system/core-workflows/learn-by-example.rst:215 +#: ../system/core-workflows/learn-by-example.rst:221 +msgid "always be hidden." msgstr "" -#: ../system/core-workflows/learn-by-example.rst:0 -msgid "Hiding the handover field in core workflows" +#: ../system/core-workflows/learn-by-example.rst:224 +msgid "**Handover** *hide*" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:125 -msgid "Showing handover field and setting it to mandatory" +#: ../system/core-workflows/learn-by-example.rst:227 +#: ../system/core-workflows/learn-by-example.rst:284 +msgid "Workflow 2" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:229 +msgid "This workflow shows the field and sets it as mandatory when another ticket owner is selected. This workflow has the default priority so it runs after Workflow 1." +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:251 +msgid "**Owner** *is modified*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:261 +msgid "**Handover** *show*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:262 +msgid "**Handover** *set mandatory*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:265 +#: ../system/core-workflows/learn-by-example.rst:290 +msgid "Trigger" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:267 +msgid "As mentioned above, the content of the field has to be written as a ticket article by a trigger. An example configuration of such a trigger could look like this:" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:271 +msgid "Condition: **Handover** *has changed*" +msgstr "" + +#: ../system/core-workflows/learn-by-example.rst:272 +msgid "Action: **Article** > **Note** with variable ``#{ticket.handover}`` in body" msgstr "" #: ../system/core-workflows/learn-by-example.rst:0 -msgid "Showing the handover field and set it as mandatory" +msgid "Hiding the handover field in core workflows" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:130 -msgid "Trigger writing handover input to a new article" +#: ../system/core-workflows/learn-by-example.rst:0 +msgid "Showing the handover field and set it as mandatory" msgstr "" #: ../system/core-workflows/learn-by-example.rst:0 -msgid "Write handover content to a new article" +msgid "Write the content of the handover field to an article by a trigger" msgstr "" -#: ../system/core-workflows/learn-by-example.rst:132 +#: ../system/core-workflows/learn-by-example.rst:296 msgid "As a result, the ticket includes an article of the type note which includes the predefined text and the handover comment." msgstr "" -#: ../system/core-workflows/limitations.rst:6 -msgid "Core Workflows do not replace Triggers" +#: ../system/core-workflows/limitations.rst:7 +msgid "Core workflow changes are checked by the application server" msgstr "" #: ../system/core-workflows/limitations.rst:5 +msgid "All changes to attributes are checked by the application server. This can have a performance impact on instances with many core workflows and/or high load." +msgstr "" + +#: ../system/core-workflows/limitations.rst:11 +msgid "Core workflows do not replace triggers" +msgstr "" + +#: ../system/core-workflows/limitations.rst:10 msgid "Workflows manipulate the behavior of fields. However, they do not set values in fields because of actions." msgstr "" -#: ../system/core-workflows/limitations.rst:16 +#: ../system/core-workflows/limitations.rst:21 msgid "API calls are only partly affected" msgstr "" -#: ../system/core-workflows/limitations.rst:9 +#: ../system/core-workflows/limitations.rst:14 msgid "Some options affect UI only and thus do not restrict responses and calls." msgstr "" -#: ../system/core-workflows/limitations.rst:11 +#: ../system/core-workflows/limitations.rst:16 msgid "This affects the following actions:" msgstr "" -#: ../system/core-workflows/limitations.rst:13 +#: ../system/core-workflows/limitations.rst:18 msgid "select" msgstr "" -#: ../system/core-workflows/limitations.rst:14 +#: ../system/core-workflows/limitations.rst:19 msgid "auto select" msgstr "" -#: ../system/core-workflows/limitations.rst:15 +#: ../system/core-workflows/limitations.rst:20 msgid "show" msgstr "" -#: ../system/core-workflows/limitations.rst:16 +#: ../system/core-workflows/limitations.rst:21 msgid "hide" msgstr "" -#: ../system/core-workflows/limitations.rst:25 +#: ../system/core-workflows/limitations.rst:30 msgid "Some fields stay unavailable to customers" msgstr "" -#: ../system/core-workflows/limitations.rst:19 +#: ../system/core-workflows/limitations.rst:24 msgid "For technical and security reasons, some default fields (the pale ones you can't edit) stay unavailable for display and usage on customer permissions." msgstr "" -#: ../system/core-workflows/limitations.rst:23 +#: ../system/core-workflows/limitations.rst:28 msgid "If you require your customers to change e.g. priorities, please consider using workarounds via :doc:`/system/objects` and :doc:`/manage/trigger`." msgstr "" -#: ../system/core-workflows/limitations.rst:29 +#: ../system/core-workflows/limitations.rst:34 msgid "Ticket title changes not supported in edit mask" msgstr "" -#: ../system/core-workflows/limitations.rst:28 +#: ../system/core-workflows/limitations.rst:33 msgid "It is currently not possible to perform changes of the ticket title in the edit mask (e.g. renaming, set to read-only)." msgstr "" -#: ../system/core-workflows/limitations.rst:33 +#: ../system/core-workflows/limitations.rst:38 msgid "Ticket text changes not supported in edit mask" msgstr "" -#: ../system/core-workflows/limitations.rst:32 +#: ../system/core-workflows/limitations.rst:37 msgid "It is currently not possible to perform changes of the ticket text in the edit mask (e.g. set to read-only)." msgstr "" -#: ../system/core-workflows/limitations.rst:41 -msgid "What is out of scope of Core Workflows?" +#: ../system/core-workflows/limitations.rst:46 +msgid "What is out of scope of core workflows?" msgstr "" -#: ../system/core-workflows/limitations.rst:36 +#: ../system/core-workflows/limitations.rst:41 msgid "There are some things that would count as workflow but are either done via :doc:`/manage/trigger` or :doc:`/manage/scheduler`." msgstr "" -#: ../system/core-workflows/limitations.rst:39 +#: ../system/core-workflows/limitations.rst:44 msgid "Such as (but not limited to):" msgstr "" -#: ../system/core-workflows/limitations.rst:41 -msgid "up- or downgrade permissions of users" +#: ../system/core-workflows/limitations.rst:46 +msgid "Up- or downgrade permissions of users" msgstr "" -#: ../system/core-workflows/limitations.rst:42 -msgid "affecting article creation or listing" +#: ../system/core-workflows/limitations.rst:47 +msgid "Affecting article creation or listing" msgstr "" #: ../system/data-privacy.rst:2 @@ -21576,6 +21674,10 @@ msgstr "" msgid "If you leave the Icon URL empty, Zammad will use the Zammad logo instead. The icon should be a square PNG file." msgstr "" +#: ../system/integrations/slack.rst:88 +msgid "The Result" +msgstr "" + #: ../system/integrations/slack.rst:90 msgid "The following figure shows how it will look if you choose to receive updates on created and updated tickets. On every post Zammad sends to the Slack channel, you can create new threads to discuss about the new article." msgstr "" diff --git a/system/core-workflows.rst b/system/core-workflows.rst index c50e5aa1..c6aab80b 100644 --- a/system/core-workflows.rst +++ b/system/core-workflows.rst @@ -1,18 +1,18 @@ Core Workflows ============== -Core Workflows allow you to adjust object attributes in many ways. +Core workflows allow you to adjust object attributes in many ways. For example: -* Show / hide fields -* Adjust mandatory setting -* Manipulate available options +* Show and hide fields +* Adjust if fields are mandatory or not +* Set available options for select fields -With this, you can provide exactly the information your users really need! +This allows you to provide exactly the information that your users really need. .. note:: - * If the pre-defined :doc:`/system/objects` are not enough, + * If the pre-defined :doc:`object attributes` are not enough, please add custom object attributes first. * If you experience slow or unreliable field updates, please see :ref:`Core Workflow Ajax Modus ` @@ -20,11 +20,6 @@ With this, you can provide exactly the information your users really need! Please ensure to test your use cases after configuration to reduce surprises. -.. figure:: /images/system/core-workflows/add-new-workflow.png - :alt: Dialogue for adding a new workflow - :align: center - :width: 75% - .. toctree:: :maxdepth: 1 :caption: Learn more diff --git a/system/core-workflows/how-do-they-work.rst b/system/core-workflows/how-do-they-work.rst index d38bdde1..30d6efae 100644 --- a/system/core-workflows/how-do-they-work.rst +++ b/system/core-workflows/how-do-they-work.rst @@ -1,22 +1,13 @@ How do they work? ================= -Core Workflows are executed according to their priority. -If two workflows have the same priority, they are executed in alphabetical -order based on their **name**. - -Because of the way Core Workflows work, all changes to attributes -are checked with the application server - please see :doc:`limitations` -for possible issues. - -Below we're talking about settings that are important and not self-explanatory. +Find a description of the different parts of the core workflows below. Object ------ Choose the object context you want to run the workflow in. This will decide on your available attributes and actions. - Ticket objects also have access to the ticket customer. Context @@ -38,6 +29,8 @@ Conditions Zammad differentiates between selected and saved conditions. These can be combined wherever needed. +You can find a description of the condition operators for core workflows in +:doc:`/system/core-workflows/condition-operators`. .. warning:: **⚠️ Restrict workflows to specific roles if needed!** @@ -63,27 +56,20 @@ Saved Conditions Example: you can't perform any actions with *saved condition* on a ticket in creation, because there are no saved values at that time. -You can find a description of the condition operators for core workflows -:doc:`here `. - Action ------ -Which actions should we run on the relevant fields? +Define which actions should get applied to the relevant fields. The possible actions depend on the object type. However, usually you can at least change the visibility and whether the field is mandatory. Be aware that actions are not available for **related** context. - -**Example:** Let's assume you are working in the ticket context. +Example: Let's assume you are working in the ticket context. While you can have customer *conditions*, you *can't adjust* objects with actions in that scope. That's because this wouldn't have any impact on the ticket dialog. Of course all ticket attributes (state, owner, ...) are available. -Please also have a look at our :doc:`limitations` to be safe -from surprises. - Available Operators ------------------- @@ -171,20 +157,19 @@ unset readonly |ui| Stop after match ---------------- -Here you can decide if other workflows are executed after the current one. +Decide if other workflows are executed after the current one. If set to ``no`` (default), further workflows will be executed if they match the condition. In this case, it is possible that your actions from the current workflow can be overwritten by another workflow. - If set to ``yes``, no further workflows will be executed after the current one. Priority -------- -You can define the sequence, in which the workflows are executed. The default -value is ``500``. +You can define the sequence of execution of the workflows by settings a numeric +value. The execution runs in ascending order. That means lower values +(e.g. ``100``) are executed before higher ones (e.g. ``999``). -The workflows are executed in ascending order by their priority. That means -lower values (e.g. ``100``) are executed before higher ones (e.g. ``999``). +The default value is ``500``. diff --git a/system/core-workflows/learn-by-example.rst b/system/core-workflows/learn-by-example.rst index 2c2ad8b8..4e0f381a 100644 --- a/system/core-workflows/learn-by-example.rst +++ b/system/core-workflows/learn-by-example.rst @@ -1,133 +1,297 @@ Learn by Example ================ -This page provides some basic examples for Core Workflows. Of course you can -build much more complex workflows if needed. To learn about Core Workflows in -detail, first go to :doc:`how-do-they-work`. +This page showcases some examples for core workflows. To learn about core +workflows in detail, first go to :doc:`how-do-they-work`. + +Basics +------ + +All core workflow examples below are configured in the same system. Compared to +a fresh installation of Zammad, the system has some additional groups and some +custom object attributes you can find in the respective examples. +See these examples as inspiration and adapt the workflows to your processes. + +Group Based Fields +------------------ + +Often, different teams (like sales, support, or 2nd level) need slightly +different workflows to handle tickets effectively. Group-based workflows allow +you to customize the ticket experience by defining the fields displayed, the +required input and the available options based on the group assigned to the +ticket. + +Problem/scenario + When a ticket is created in or moved to the ``2nd Level`` group, the category + field must be limited, some fields have to be shown and specific fields + are mandatory to have all relevant information for the 2nd level support + present in the ticket. + +Workflow configuration + .. list-table:: + :widths: 20,50,30 + :header-rows: 1 -Group Based Examples --------------------- + * - Area + - Configuration + - Note -All following workflows have the same base configurations. -The workflow may not use them all. + * - Object + - Ticket + - -* Groups: + * - Context + - - Creation mask + - Edit mask + - + + * - Selected conditions + - **Group** *is* ``2nd Level`` + - + + * - Saved conditions + - + - Not used because the UI has to change + + immediately when the group is set to 2nd Level. - * Sales - * Support - * 2nd Level -* Attributes: + * - Action + - - **Category** *show* + - **Category** *set fixed to* ``2nd Level`` (and all sub categories) + - **Operating System** and **Software used** *show* + - **Operating System** and **Software used** *set mandatory* + - + +Configuration in UI + .. figure:: /images/system/core-workflows/examples/1_group-specific-fields-and-values_2nd-level.png + :alt: Sample workflow that shows specific values and fields for 2nd level + :width: 70% - * Category (Single tree selection field, not mandatory, agents only) - * Approved (Boolean field, not mandatory, not shown, ``false`` as default) - * Operating System (Text field, not mandatory, not shown) - * Software used (Single selection field, not mandatory, not shown) +Approval Process +---------------- -1. Group specific values and fields - This workflow set depends on the category field. - It reduces the available set of values based on the group selected. +In many organizations, an approval is required to initiate subsequent processes. +This approval is usually limited to a specific group of people to ensure that +all requirements for the subsequent process are fulfilled. - .. tabs:: +Problem/scenario + The approval of a customer issue can only be done by users with the role + ``Approval Person``. As long as this approval has not been done, the value + must be set fixed to ``no``, unless the approval person views the ticket. - .. tab:: Workflow 2nd Level group + Based on the approval state, additional automation processes can be + established (e.g. a trigger to raise the priority or assign a specific agent). + +Workflow configuration + .. list-table:: + :widths: 20,50,30 + :header-rows: 1 - This reduces the category options to ``2nd Level/*``, - ``Internal/*`` and ``Others``. It also sets further required - fields to mandatory and visible. + * - Area + - Configuration + - Note - .. figure:: /images/system/core-workflows/examples/1_group-specific-fields-and-values_2nd-level.png - :alt: Sample workflow that shows specific values and fields for 2nd level - :width: 90% + * - Object + - Ticket + - - .. tab:: Workflow Support group + * - Context + - - Creation mask + - Edit mask + - - This reduces the category options to ``Support/*``, - ``Internal/*`` and ``Others``. It also sets further required - fields to visible. + * - Selected conditions + - **Role** *is not* ``Approval Person`` + - Checks if role is not ``Approval Person`` for unsaved - .. figure:: /images/system/core-workflows/examples/1_group-specific-fields-and-values_support.png - :alt: Sample workflow that shows specific values and fields for support - :width: 90% + changes in the ticket. - .. tab:: Workflow Sales group + * - Saved conditions + - **Approved** *is not* ``yes`` + - Checks if the approval is not yet set to ``yes``. - This reduces the category options to ``Sales/*``, - ``Internal/*`` and ``Others``. + * - Action + - **Approved** *set fixed to* ``no`` + - Prevents changes when above conditions are met. - .. figure:: /images/system/core-workflows/examples/1_group-specific-fields-and-values_sales.png - :alt: Sample workflow that shows specific values and fields for sales - :width: 90% +Configuration in UI + .. figure:: /images/system/core-workflows/examples/2_role-specific-approval-settings.png + :alt: Sample workflow that restricts an approval attribute to specific roles + :width: 70% - The Result - This is what the agent would experience with the above - workflows in place. +Enforcing Ticket Categorization +------------------------------- - .. figure:: /images/system/core-workflows/examples/1_group-specific-fields-and-values_result.gif - :alt: Workflow shows objects and limits options based on selections on the group - :width: 90% +To have convincing numbers for your statistic, it can be a good idea to enforce +certain attributes to be populated before the ticket can be closed. -2. Approval process - In this case ``approved`` is visible to agents by default. - For this workflow, an additional role ``Approval person`` is required - (no further permissions). +Problem/scenario + The ``Category`` field must be set to mandatory if an agent wants to set the + states ``closed`` or ``pending close`` to enforce categorization. - .. figure:: /images/system/core-workflows/examples/2_role-specific-approval-settings.png - :alt: Sample workflow that restricts an approval attribute to specific roles - :width: 90% - .. tip:: +Workflow configuration + .. list-table:: + :widths: 20,50,30 + :header-rows: 1 - This workflow may work best in combination with a - :doc:`trigger ` but technically, this is not required. + * - Area + - Configuration + - Note - Select fields may be a better approach because they allow more - values than just a simple ``true`` or ``false``. + * - Object + - Ticket + - - The result - .. figure:: /images/system/core-workflows/examples/2_role-specific-approval-settingsl_result.gif - :alt: Workflow fixes possible values of "Approved ?" to a specific selection depending on the users role - :width: 90% + * - Context + - - Creation mask + - Edit mask + - -3. State dependent mandatory fields - This workflow sets ``Category`` to mandatory if the agent wants to set the - states ``closed`` or ``pending close`` to enforce categorization. + * - Selected conditions + - **State** *is* ``closed`` or ``pending close`` + - Selected condition because it has to be - .. figure:: /images/system/core-workflows/examples/3_state-dependent-mandatory-fields.png - :alt: Sample workflow that sets fields to mandatory on specific states - :width: 90% + checked before changes are saved. - The result - .. figure:: /images/system/core-workflows/examples/3_state-dependent-mandatory-fields_result.gif - :alt: Workflow sets category field to mandatory upon choosing closed or pending close as state - :width: 90% + * - Action + - **Category** *set mandatory* + - -Manual Ticket Handover Process ------------------------------- +Configuration in UI + .. figure:: /images/system/core-workflows/examples/3_state-dependent-mandatory-fields.png + :alt: Sample workflow that sets fields to mandatory on specific states + :width: 70% -This example covers the handover of a ticket from one agent to another: -- When the ticket owner is modified, a new text field ("Handover") shows up - for a comment -- This may only be visible when the owner is changed, therefore it has to - be hidden in general -- The input in this handover text field is mandatory -- After submitting changes, the value of the handover field must be added as an - note to the ticket (via trigger) +Ticket Handover Process +----------------------- -Hiding handover field - .. figure:: /images/system/core-workflows/examples/example-handover-hide.png - :alt: Hiding the handover field in core workflows - :width: 90% +A handover from one agent to another might require more than just a change of +the owner. Depending on the issue or process, it can be very helpful that the +original agent leaves a small note so the new agent knows immediately what's the +reason for the handover and where to start. -Showing handover field and setting it to mandatory - .. figure:: /images/system/core-workflows/examples/example-handover-show.png - :alt: Showing the handover field and set it as mandatory - :width: 90% +Problem/scenario + Agents must write a small comment when they want to change the ticket owner. + There is a custom ticket attribute called ``Handover`` where a text can be + inserted. This field is hidden by default (Workflow 1) and only shows up + when the owner changes. Additionally, it must be set to mandatory in such a + case (Workflow 2). -Trigger writing handover input to a new article - .. figure:: /images/system/core-workflows/examples/example-handover-trigger.png - :alt: Write handover content to a new article - :width: 90% + Because the field is hidden after saving the change of the ticket owner, the + text of the field has to be written to the ticket as an article by a trigger. + Otherwise, the new agent would not see it at all. -As a result, the ticket includes an article of the type note which includes -the predefined text and the handover comment. +Workflow configuration + .. tabs:: + + .. tab:: Workflow 1 + + This workflow hides the field in general. Please note the lower + priority which tells Zammad to execute this workflow first. + + .. list-table:: + :widths: 20,50,30 + :header-rows: 1 + + * - Area + - Configuration + - Note + + * - Object + - Ticket + - + + * - Context + - - Creation mask + - Edit mask + - + + * - Selected conditions + - + - No condition needed, because it should + + always be hidden. + + * - Saved conditions + - + - No condition needed, because it should + + always be hidden. + + * - Action + - **Handover** *hide* + - + + .. tab:: Workflow 2 + + This workflow shows the field and sets it as mandatory when another + ticket owner is selected. This workflow has the default priority so + it runs after Workflow 1. + + .. list-table:: + :widths: 20,50,30 + :header-rows: 1 + + * - Area + - Configuration + - Note + + * - Object + - Ticket + - + + * - Context + - - Creation mask + - Edit mask + - + + * - Selected conditions + - **Owner** *is modified* + - Selected condition because it has to be + + checked before changes are saved. + + * - Saved conditions + - + - + + * - Action + - - **Handover** *show* + - **Handover** *set mandatory* + - + + .. tab:: Trigger + + As mentioned above, the content of the field has to be written as a + ticket article by a trigger. An example configuration of such a trigger + could look like this: + + - Condition: **Handover** *has changed* + - Action: **Article** > **Note** with variable + ``#{ticket.handover}`` in body + +Configuration in UI + .. tabs:: + + .. tab:: Workflow 1 + + .. figure:: /images/system/core-workflows/examples/example-handover-hide.png + :alt: Hiding the handover field in core workflows + :width: 70% + + .. tab:: Workflow 2 + + .. figure:: /images/system/core-workflows/examples/example-handover-show.png + :alt: Showing the handover field and set it as mandatory + :width: 70% + + .. tab:: Trigger + + .. figure:: /images/system/core-workflows/examples/example-handover-trigger.png + :alt: Write the content of the handover field to an article by a trigger + :width: 70% + + As a result, the ticket includes an article of the type note which includes + the predefined text and the handover comment. diff --git a/system/core-workflows/limitations.rst b/system/core-workflows/limitations.rst index 88fc1144..04069b79 100644 --- a/system/core-workflows/limitations.rst +++ b/system/core-workflows/limitations.rst @@ -1,7 +1,12 @@ Limitations =========== -Core Workflows do not replace Triggers +Core workflow changes are checked by the application server + All changes to attributes are checked by the application server. This can + have a performance impact on instances with many core workflows and/or high + load. + +Core workflows do not replace triggers Workflows manipulate the behavior of fields. However, they do not set values in fields because of actions. @@ -10,10 +15,10 @@ API calls are only partly affected This affects the following actions: - * select - * auto select - * show - * hide + * select + * auto select + * show + * hide Some fields stay unavailable to customers For technical and security reasons, some default fields (the pale ones @@ -32,11 +37,11 @@ Ticket text changes not supported in edit mask It is currently not possible to perform changes of the ticket text in the edit mask (e.g. set to read-only). -What is out of scope of Core Workflows? +What is out of scope of core workflows? There are some things that would count as workflow but are either done via :doc:`/manage/trigger` or :doc:`/manage/scheduler`. Such as (but not limited to): - * up- or downgrade permissions of users - * affecting article creation or listing + * Up- or downgrade permissions of users + * Affecting article creation or listing