Nimbus comes with a set of Workflow templates which are can be applied in a service's respective Modality Service Settings. The core principle behind workflow templates is standardization and inheritance of workflow structures to all workflows
☝Please note: Workflow Templates are a powerful tool to standardize task handling across your services and modalities. However, they can also act destructively as any change on a template may impact multiple productive services at once. → Please read this chapter carefully and roll out templates gradually to test the effects of changes.
☝There are two types of templates:
-
"System" Workflow Templates are defaults you can start with.
Changes on system templates are rolled out by Luware, but do not automatically inherit changes to existing workflows. -
Custom Workflow Templates are of your own design. You can start blank or pre-filled with system template contents.
Your workflows keep a reference “based on” their any template. As your template is changed, children inherit those changes.
✅ TENANT ADMIN / OU ADMIN Requirement: Workflow Templates are managed by users with Admin Roles within the Nimbus Admin Portal. Team and Service owners may create and edit workflows on the Frontend, but not define or change templates.
Creating a Workflow Template
✅ To create a new Workflow Template, perform the following steps:
- Log into the Nimbus admin portal with an Administrator role.
- Navigate to "Configuration > Workflows > Workflow Templates" → A list of existing templates will be shown to you.
- Define a Name and Organization Unit for your new template. 💡 This determines where (and if) other users get to use this template when creating their own workflows.
-
Select a "Workflow Template" from the list. 💡 You can use any of the available System Templates so you don't have to start from scratch.
- Click Create to start editing your Workflow Template.
🤔 What's the technical difference between Workflow Templates and regular Workflows?
- Workflows created from templates will be “based on” that template. Aside from that reference there is no technical or structural difference.
- Every workflow is will inherit template changes as long as it clearly can be associated (e.g. the same activity or property inside the template). If the source (template) is deleted, the workflow becomes independent and will not react to template changes anymore.
- A "reattachment" of a template to a new workflow is not possible. In case of a deleted template you need to create a new template and base your new workflows on it.
🤔 What are "System Templates" and how do they differ from "Custom Templates"?
- System Templates provided by Luware are structurally identical to your own user Custom Templates and use the same workflow activities. However:
- System Templates act as a stable baseline for new workflows and templates and cannot be changed.
- Whenever Luware opts to change a base System Template (e.g. during Nimbus updates) your productive workflows are not affected by these changes.
- Luware will also announce changes in our release notes and with advance communication.
- If you want to make use of new features introduced in System Templates, you can do so manually by updating our existing Custom templates or workflows directly.
🤔 Why can I not select my own existing "Custom" Workflow Templates as a starting point?
Currently only System Templates are allowed as starting point for new templates. In a future update we intend to allow custom Custom Templates as well. However, this can result in complex dependency and "nesting" scenarios that must be clearly communicated in both visual UI and the technical long-term implications.
Editing a Workflow Template
Once you create a new Template (or edit a previously created one) you will be brought right into the Workflow editor. The Workflow Editing experience will be exactly the same, and you can make use of all Workflow Activities to modify your template.
However, there are some slight differences towards the normal workflow editing process:
| Template Concept | Description | UI Differences |
|---|---|---|
| Locking | You can lock the entire workflow or individual elements in your template against change. The following elements in a tempalte can be locked:
🔍 Compared to regular workflows, only the template will show these locking controls in the UI.
The concept of locking also brings “inheritance” effects, which is explained in chapter → “Locking of Workflow Templates” below.
|
 Locking of Workflow > Structure > Activity > Property
|
| Available Activities (based on License) | Enterprise Routing Contact Center Certain workflow elements are tied to licensed Nimbus Features. Templates however will always show all available Workflow Activities. 🔍 Depending where a workflow template is used, a warning might be shown that these features are limited by the service license.  The licensing of the service can be changed via Service Administration.
|
Templates show all activities, even licensed ones
|
Locking of Workflow Templates
Workflow Templates can be locked against changes, signaled by a red font color and lock symbol. These changes propagate through to any template.
| Example: Workflow Template editing | Example: Workflow editing (based on template) |
|---|---|
|
💡 This workflow template has the structure locked. In this example any workflow based on this template is configured as follows:
|
💡This is the same workflow based on the template. Using our example from the left column of this table we can now see the effects:
|
 |
 |
Lock options and effects
While editing a workflow template you have the following options with the following effect on your templates:
| Option in workflow template | Effect on workflows using the template |
|---|---|
|
Lock entire workflow
|
Workflows cannot be changed at all. ⮑ Lock effects are as follows:
|
|
Lock workflow structure
|
⮑ Lock effects are as follows:
We strongly recommend to keep at least your template structure locked when you intend to lock activities and their individual properties as well. This also ensures that later template changes are clearly propagated to dependent templates. ☝ Keep in mind: When the template structure is left unlocked, but has locked activities, Service owners might just drag in a new (property-unlocked) activity from the list, effectively overriding your template locks. Of course you can keep this intentionally “open”, treating any locks as a suggestion. |
|
Lock workflow activity (header)
|
⮑ Lock effects are as follows:
Good to know: Previous lock states on individual properties are preserved (greyed out) in case you want to re-use them later. → Workflows will show the activity slightly toned. Their contents and properties can be inspected, but not changed at all. |
|
Lock activity properties (in body)
|
⮑ Lock effects are as follows:
Caution - Changes to locked properties will be propagated to existing workflows. → The affected workflows based on your template will be listed in an additional confirmation popup. |
Saving changes to existing templates
Workflow Templates are a powerful feature, which can help standardize your service workflows. However, they can also have effects that may impact your services with unintended side-effects.
Please Note before changing Templates in productive use
As you save your Workflow Template, Nimbus will always show a warning message to make you aware of its effects.
☝Any change to your template will affect (existing or future) workflows based on this template. If any workflows are affected by the template they are listed in the warning message.
☝ Workflows based on your template will get their locked properties and structure overwritten by your template changes.
→ Refer to the “How are changes on templates propagated” section below for details. Ensure that the affected services are not negatively impacted by the change (e.g. on a previously unlocked property that was free to adjust for services owners).
☝ Saved template changes are invisible and immediate to other service owners. Effects can be be minor, such as a Playlists changing to a new default, but also major like an entire Queue Activity Distribution setting or structure changing, thus affecting multiple services and their KPI.
🤔 How can I check which services are affected by my template changes?
To avoid issues caused by template changes, head to your Workflows and verify which of your workflows are template-based and actively used in your services.
Show me an example
Some considerations to take:
☝ Services located in (Sub-)Organization Units can access the same template and create workflows from it.
✅ Checklist:
- After a template change you might want to check if a dependent workflow is still fully applicable for all related services. For example, a (newly) locked "language" property in your announcements could your international services as well.
- A check is also necessary when Organization Units (OU) within your company change. Your workflow template could become suddenly available to new services that rather shouldn't use it.
☝ Templates currently not "used in a service" are safe to change, but may get redundant or outdated over time.
✅ Checklist:
- Perform regular "clean-up" checks to see if you can consolidate, remove or update your older templates.
- You may want to move unused and “experimental” templates to a different Organization Unit to keep them out of view from productive services.
☝ Workflows NOT "based on" a template will not receive template changes.
✅ Checklist:
- It can be beneficial to leave workflows "based on" no template at all, allowing some services full flexibility and avoiding impacts by template changes.
- If you want to introduce quality-control or standardization to your workflows, consider re-creating them "based on" a template. You can leave the structure lock open so the template just acts as a “baseline suggestion”.
✅ GENERAL TIP: Ensure to inform your service owners and fellow administrators before making any sweeping changes on productive templates, particularly those located on high Organization Unit level, as they are highly visible and available to many services simultaneously.
🤔 How are changes on templates propagated?
Depending on what you change in a template, the effects are as follows:
| Cause / Action Taken | Effect |
|---|---|
| Workflow or Structure are locked. | Any changes, like adding/removing activities and adding/removing exits in the template will be propagated to its workflows. |
|
Parent Activity locked, Destination activity is removed. |
The destination activity removal will not be propagated, because there’s no structure/workflow lock in place. The exit from the parent activity is removed automatically in the template, as no exit can exist without a destination activity. |
| Parent Activity locked, Destination activity is added. |
The destination activity creation will not be propagated, because there’s no structure/workflow lock in place. The exit from parent activity is added in the template, but since the activity was not added to the workflow, the exit cannot be added either, as it cannot point to an “empty” destination. |
✅ GENERAL TIP: If you want to propagate structural changes in future, at least a structure lock must be in place. Note that in this case all dependent workflows will get a full structure update (i.e all activities and connections between them will be matched to the template).
System Templates
💡Out of box Nimbus comes with a baseline set of following Workflow "System" Templates. System templates are managed by Luware and may change in future updates as the possibilities of Nimbus gets expanded with more Workflow Activities.
💡System Templates are generally "safe to use" recommendations as your baseline for your own workflows and templates. Even as System Templates get changes during Nimbus updates, your existing workflows will not be affected by those changes.
☝ System Templates may contain additional licensed activities and Nimbus Features. Certain activities in System Templates make use of Enterprise Routing and Contact Center Nimbus Features .
- You may create workflows from these templates, but to apply them in your Modality Service Settings unless your service is licensed for it. → Also see License Management.
- Vice-versa, a License downgrade of existing services will also be prevented while license-dependent Workflow Activities are still part of the workflow.
🔎 In our Workflow Activities documentation you can find license flags and a matrix of activities with license dependencies.
Audio / Video Templates
Audio / Video These templates are available in the baseline Nimbus installation with the Audio / Video modality. Note that other supported modalities may come with different templates.
IVR Transfer
A simple IVR transfer based on calling customer choice. You can transfer to separate service teams (e.g. proficient in a special language or providing the know-how that the customer requires).
Opening Hours Queue Disconnect
The "Opening Hours" Workflow allows for more variety in managing your Service. You can configure Opening Hours in the → Modality Service Settings.
Opening Hours Queue Voicemail
Enterprise Routing - please note that this workflow contains workflow activity Features requiring an Enterprise Routing license.
An advanced workflow that tries to distribute customers directly to the next available team member. Calls unanswered or outside of opening hours will go to voicemail.
Opening Hours Queue Voicemail Transfer
An advanced workflow that tries to distribute customers directly to the next available team member. During open hours the calls will go to voicemail, on special or closed hours a transfer to a backup-service is arranged.
Pickup Disconnect
Enterprise Routing - please note that this workflow contains workflow activity Features requiring an Enterprise Routing license.
A simple task distribution workflow that will play music and an announcement until the maximum queue time is reached. A regular check is in place to keep the user informed of the ongoing queue distribution.
Queue Disconnect
A simple queue workflow with a defined playlist and set queue time. Once the maximum wait time is reached the caller gets disconnected.
Queue IVR Voicemail
Enterprise Routing - please note that this workflow contains workflow activity Features requiring an Enterprise Routing license.
An advanced task distribution workflow that checks regularly if the either the customer via choice wants to exit or if the maximum queue time limit is reached. The call is then put to voice message.
Queue Transfer
A simple workflow that queues the user for distribution and transfers to another service when the queue time is exceeded.
Queue Voicemail
A simple workflow that queues the user for distribution and goes to voicemail if the queue time is exceeded.
