Workflow Templates

Workflow standardization and change management

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.

Workflow Templates are “used in” (new or existing) workflows, but can also be based on other templates

Creating a Workflow Template

✅ To create a new Workflow Template, perform the following steps: 

  1. Log into the Nimbus admin portal with an Administrator role. 
  2. Navigate to "Configuration > Workflows > Workflow Templates" → A list of existing templates will be shown to you. 
  3. 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.
  4. 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. 
  5. 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

You can lock the entire workflow or individual elements in your template against change. The following elements in a tempalte can be locked

  • The entire workflow
  • The workflow structure
  • An activity header
  • An activity property

🔍 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.




From top to bottom: 
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
In templates, all activities can be used, regardless of licensing restrictions.


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:


  • Activities and their connections (nodes) cannot be changed.
  • Certain properties remain unlocked, so they can be changed.
  • Locking an entire activity in the template will display locks as greyed out by the workflow activity itself.

💡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:


  • Nodes between activities are now locked against change. 
  • Only specific properties can be changed in the workflow.
  • Entire locked activities are also "read only" and shown as slightly faded.
A partially locked Workflow Template
A workflow based on the Template

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:

  • ❌ Prevents addition or deletion of workflow activities.
  • ❌ Locks all existing workflow activity connections (nodes with arrows) against change.
  • ❌ Prevents changes to any existing activity property.

Lock workflow structure

⮑ Lock effects are as follows:

  • ❌ Prevents addition or deletion of workflow activities.
  • ❌ Locks all existing workflow activity nodes (arrows) against change.
  • Allows changes to activity properties.

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:

  • ❌ Prevents changes to all properties in that particular activity.
  • Allows addition or deletion of workflow activities.
  • Allows workflow activity nodes (arrows) to be changed.

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:

  • Prevents changes to individual activity properties.
  • Allows addition or deletion of workflow activities.
  • Allows workflow activity nodes (arrows) to be changed.

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. 
→ Ensure that the affected services are not negatively impacted by the change. Also see “Saving changes on existing templates”.


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

This example shows a list of workflows both “used in services” and “based on” a template.

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 . 

🔎 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.


Table of Contents