Nimbus comes with a set of base "System" Workflow Templates to use as fixed baseline for your new workflows. Alternatively you can design your own Custom Workflow Templates, starting with a – either blank or pre-filled – System Template. Your templates keeps a reference to any "children" workflows. As your template is changed, children inherit those changes automatically.
✅ TENANT ADMIN / OU ADMIN Workflow Templates are managed by users with Administrator Role within the Nimbus Admin Portal.
☝ Please note : Workflow Templates are a powerful tool to standardize call handling across your services – but also can act destructively as any change on a template can impact multiple productive services at once. → Please read this chapter carefully and roll out templates gradually to test the effects of changes.
🔍 User Access: Team and Service owners may create and edit workflows on the Frontend, but not define 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 are considered "instances" of that template. Aside from that reference there is no technical or structural difference.
- Every Template is considered an instance as long as it clearly originates from an existing source. If the source (template) is deleted, the instance becomes independent and will not react to template changes anymore.
- A "reattachment" of a template to a new instance is not possible. In case of a deleted template you need to create a new template and base your new workflows instances on it.
🤔 What are "System Templates" and how do they differ from "Custom Templates"?
-
System Templates provided by Luware are structurally identical to Custom Templates, using the same workflow activities and properties. However:
- System Templates act as a stable baseline for new workflows and templates and cannot be changed by users.
- When Luware opts to change a base System Template (e.g. during Nimbus updates) your productive workflows and template instances are not affected.
- 💡 We will also announce such changes in our release notes and advance communication.
🤔 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 UI and the technical 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:
| Concept | Description | UI Differences |
|---|---|---|
| Template Locking | You can lock the entire workflow or individual elements in your template against change. 🔍 Compared to regular workflows, a template has special locking controls in the UI. This concept is explained in further detail below . |
Locking controls are exclusive to templates
|
| 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 is used, a warning might be shown that these features are limited by the license applied on the target type of service. 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 instance.
| Example: Workflow Template editing | Example: Workflow Instance editing |
|---|---|
|
💡 This workflow template has the structure locked
|
💡 This is the same workflow instance based on the template.
|
 |
 |
While editing a workflow tempalte you have the following options at your disposal:
| Option | Effect |
|---|---|
| Lock Workflow | The entire template is locked. Workflows based on it cannot be changed at all.
|
| Lock Structure | The template structure is locked. Workflows based on it can still be changed in property details.
We recommend to keep your template structure locked when you intend to lock activities and indiviudal properties as well. Otherwise, service owners might just drag in new (unlocked) activies from the list, effectively overriding your locks. |
| Lock Activity (Activity Header) | The template activity is locked. Workflows based on it can still be changed in their structure.
❌ Prevents changes to all properties in that particular activity. 🔍 Previous lock states are saved and still shown greyed-out but are overridden by the activity lock. → Workflows based on this template show the activity slightly toned and can be inspected, but not changed at all. |
| Lock Properties (Activity Body) | The template activity properties are locked. Workflows based on it can still be changed in their structure.
|
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) workflow instances of that template. If any workflows are affected by the template they are listed in the warning message.
☝ Workflow instances 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 points of note:
☝ Services located in (Sub-)Organization Units can access the same template and create instances from it.
✅ Checklist:
- After a template change you might want to check if a dependent workflow instance is still applicable for all related services. For example, a (newly) locked "language" property could affect your international services as well.
- Vice versa, this check also applies when Organization Units (OU) within your company change, which could make your workflow instance or template suddenly available to new services that rather shouldn't access it.
☝ Templates currently not "used in a service" are safe to change, but may get redundant or outdated over time.
✅ Checklist:
- If your templates are not used, perform regular "clean-up" checks to see if you can consolidate or remove older templates during maintenance.
- You may want to move unused templates and workflows to a different Organization Unit to keep them out of view from services and prevent accidental use.
☝ Workflows not "based on" a template act as standalone instances and will not be affected by any 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.
- However – if you want to keep your workflows under a strict quality-control or easier to maintain – consider re-creating them "based on" a template.
✅ GENERAL TIP: Ensure to inform your service owners and fellow administrators before making any sweeping changes on productive templates, particularly on a high Organization Unit level, as those templates are likely to be visible 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 dependent workflow instances. |
|
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 is not created in the instance, the exit cannot be added in the instance as it cannot point to an “empty” destination. |
✅ GENERAL TIP: If you want to propagate structural changes, at least a structure lock must be in place. However, note that in this case all dependent instances will get a full structure update (i.e all activities and connections between them will be matched to the template).
List of System Templates
💡Out of box Nimbus comes with a baseline set of following Workflow "System" Templates.
These 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 when Nimbus changes System Templates, 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 unless your service needs to be licensed for it. → See License Management.
Vice-versa, a License downgrade of existing services is also prevented while license-dependent Workflow Activities are still part of the workflow. In our documentation, workflows and their Workflow Activities are marked with a license flag highlight a license requirement.
Broadcast Disconnect
A simple workflow that will simply broadcast an incoming call to all team members.
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.
