Open in ClaudeOpen in ChatGPT

Creating & Managing Workflows (For Admins)

Workflows are project management tools that let departments collaborate on shared scenarios through defined sequential steps. This guide covers how administrators create, configure and manage them.

Bildschirmfoto 2025-02-03 um 16.07.28.png

Workflows are Valsight’s internal project management tools that enable a smooth collaborative process across multiple business units and levels. We recommend Workflows for larger, cross-departmental projects such as multi-year planning and forecasting cycles. A Workflow defines how a project works. It is reusable, which is particularly useful for recurring projects such as forecasting.

How workflows work

A Workflow allows multiple teams with multiple Workspaces (i.e. EU, DE, and EN) to work on the same Scenario(s) (i.e. MYP – Base Case & MYP – Best Case) in a pre-defined order (i.e. EU – Base Assumptions -> DE & EN Measures -> EU – Consolidation).

It allows Teams to view, review and build upon previous assumptions, measures and simulations, submit their own as well as eases the control and review process of these.

The Workflows can be found under the ‘Workflows’ icon in the navigation bar on the left. The Workflow page consists of two tabs for an easier management; ‘Ongoing’ & ‘Completed’.

image-20240712-112317.png

Workflows States:

  1. Draft – A Workflow which has been created but not started yet. Can still be edited.
  2. Active – A Workflow which has been started and is currently ongoing. Only basic properties such as name can be edited.
  3. Completed – These are Workflows which have been ended once all Workflows steps have been set to ‘Done’.
  4. Canceled – Workflows which have been stopped without all steps set to done.

image-20240712-112651.png

  • Once a Workflow has been started, no new steps can be added.
  • Both completed and canceled Workflows can be duplicated and reused later.

Creating a new workflow

Click on ‘Create a Workflow’ to open the configuration dialogue. Here you will have parameters which you can set:

Base Settings: General settings for a basic Workflow

  • Name: The name of the flow. It is recommended to name it so that it is clearly understandable what it is. Keep in mind that individual contributors will have to chose it when importing or submitting their Scenarios, i.e. company forecast.

    The Scenario names that you choose in the setup of your Workflow will define the Scenarios you want people to collaborate on in your Workflow. Each user will be able to add assumptions to these Scenarios. Other users will be able to see these changes and built upon them in their own workspace.

    image2020-10-12_16-36-59.png?version=1&modificationDate=1602513419342&cacheVersion=1&api=v2&width=340&height=250

As Workflows can be repeated, it is best to not include version specifics in the name (i.e. 2024 or v1). Use the Version field for this (see below).

  • Create Scenario: Starting a Workflow will create one or more Scenarios in each chosen workspace. Individual contributors will then be able to submit their measures and assumptions in these Scenarios. To name the Scenarios, type the Scenario name followed by a comma (,). Press enter to confirm. At least one Scenario name is required, and two Scenarios in the same Workflow cannot carry the same name. You may also enter the name of a Scenario that already exists: it is included in the Workflow and created in every workspace that does not have it yet.
  • Description
  • Version: Required. Because Workflows are repeatable, the version is what tells one run of a Workflow apart from the next, i.e. ‘Q1’, ‘2024’, ‘FC 3+9’, ‘v1’… The ‘Create’ button stays disabled while the field is empty.

Workflow Scenarios are linked by name. A Scenario belongs to a Workflow because its name matches one of the Scenario names configured here, not through a hidden reference. Renaming a Scenario in the Scenario Manager therefore drops it out of the Workflow, and giving an unrelated Scenario the exact name of a Workflow Scenario pulls it in. Valsight raises a ‘Workflow Link/Unlink’ confirmation before saving such a rename, but the rename itself is allowed.

image-20240712-112516.png

Advanced Settings: These are optional settings which are necessary in case you wish to create new workspaces with starting this Workflow. I.e. a consolidation workspace.

  • Associated Model: Which model should the new workspaces be based on.
  • Associated Baseline: Which baseline should these workspace use.

The two are optional only as a pair: leave both empty, or set both. A model without a baseline blocks the creation of the Workflow with ‘Please choose a corresponding Baseline’. Changing the model clears the baseline you had already picked, so choose the model first.

New workspaces will be named after the Workflow step. To create a new workspace, simply leave the ‘Associated workspace’ field empty when creating a Workflow step (see below).

image-20240712-112537.png

Configuring the workflow

A Workflow consists of multiple Workflow steps. These have a specific order and can be dependent from one another. To configure the Workflow, click on the Workflows name once it is in ‘Draft’ stage.

Adding and editing steps is reserved for project admins. Everyone else finds the step creation button unavailable, with the tooltip ‘This function is only available to project admins’, and the step dialogue opens behind the warning ‘You do not have sufficient permissions. Only project admins can add or edit workflow steps.’

Workflow step stages:

  1. Open: The step has not been submitted yet
  2. Preview: The step has been submitted. If necessary, it can be reviewed now.
  3. Review: The step has been reviewed and promoted. If necessary, it can be reviewed a second time by another reviewer.
  4. Done: The step is reviewed and completed. No further changes are possible.

Click on the ‘Create Workflow Step’ button. To create a step, give it a name (i.e. ‘EU Base Assumptions’), optionally a description, and assign it a workspace. The description is shown with the step’s submissions, which read ‘No description’ when you leave it empty.

Not every workspace is accepted:

  • All steps must share one model tree. A step’s workspace has to be based on the Workflow’s model, or on a super- or submodel of it. A workspace from another model tree is refused with ‘All connected steps must be associated with workspaces basing on the same model’.
  • Template workspaces are not allowed in Workflows and are rejected when you confirm the step.

Leave the ‘Associated workspace’ field empty to have the Workflow create a new workspace for this step. This works only if the Workflow itself has both an Associated Model and an Associated Baseline set under Advanced Settings (see above). Without them the confirm button of a new step stays disabled, and the tooltip asks you to either select a workspace or configure the Workflow with a model and a baseline.

image-20240712-112740.png

Select a previous step if necessary. This will determine, which Workflow steps this step is dependent on.

The dependency gates promotion, not sharing. Contributors in this step can share their Scenarios whenever they like, but a Scenario only leaves ‘Preview’ once it has been shared and every input step has its Scenario of the same name on ‘Done’. Importing a previous step does not satisfy the dependency. Until it is met, Valsight refuses the status change with ‘You cannot update the status. Ensure a scenario is submitted and that all previous steps are set to Done.’

image-20240712-112803.png

Configure Permissions:

Permissions are assigned per state, not per step. The ‘Configure Permissions’ tab opens the ‘Configure state permissions’ dialogue: a table with one row per state and a ‘Users & Groups’ field on each row.

image-20240712-112841.png

Each row names the users and user groups who may move the step into that state. There are three rows, ‘Open’, ‘Preview’ and ‘Review’. ‘Done’ has no row, because no one holds rights on the final state. Leave a row blank for states which do not need to be handled by specific users, but see Email notifications for what a blank row does to the recipient list.

Permissions are the one part of a step that stays editable after the Workflow has started: no new steps can be added, but new step permissions can still be assigned.

Once the Workflow is configured, it can be started with the ‘Start’ button in the header of its Configuration page, or through the three-dot menu in the Workflow overview. This will create all Scenarios in all associated workspaces as well as create any new workspaces.

Step Order:

Workflow steps can be configured by the admin, and their order will be reflected in both the Workflow’s submissions page for an improved overview and in the workspaces. If a workspace has more than one workflow step assigned, arranging the steps in the correct order helps users navigate them more easily within the workspace.

Clicking on the sort button, right next to the search bar, will open the sorting dialogue:

Bildschirmfoto 2025-02-03 um 16.12.13.pngimage-20241101-141306.png

Workflow steps are sorted alphabetically per default. The ‘Sort order’ dropdown offers three modes: ‘Manual’, ‘Alphabetical - ascending’ and ‘Alphabetical - descending’. ‘Manual’ is the only one that lets you arrange the steps freely, so it is the mode to pick when the order above matters.

Managing ongoing workflows

Open a Workflow’s submissions page to view its progress by clicking on an active Workflow’s name.

Bildschirmfoto 2025-02-03 um 16.07.28.png

The table has one row per Workflow step and one column per Scenario. Click a submission’s name, not the status tag beside it, to open its details: the status, the workspace it came from, the full history of what has happened to it including every comment, and the actions to promote or demote it.

The header of the submission details carries a third action, ‘Update Submission Data’. It pulls the contributor’s Scenario as it stands right now and shares it as a new version on top of what was shared before, so a submission is not frozen once it has been made. It is available while the Workflow is running, and it fails with ‘The scenario ”…” is missing from the workspace ”…”’ if the contributor has renamed or deleted the Scenario in the meantime. The same update is available in bulk from the ‘Share Workflow Steps’ dialogue in the Scenario Manager.

As an admin, you can demote a Workflow step from done to review. This is only possible for admins and will also demote subsequent steps which were on done back to review.

Reviewing and consolidating steps and scenarios

To review a submission, open the subsequent steps workspace, navigate and to the Scenario manager. If a previous step has been submitted, the Workflow icon will be highlighted in orange. Click on it and open ‘Import Previous Steps’. Select the current Workflow and the step that you are in and select all previous steps.

image-20240712-113029.png

You can then check the numbers as well as any charts that you might have. If everything looks right, go back to the Workflow icon, open ‘Share Workflow Steps’ and promote the steps to the next stage. Alternatively, you can promote the steps from the Workflow’s submissions page.

Consolidating and doubling assumptions: If you have two steps which have the same previous step, they will end up importing the same assumption (I.e. inflation). When consolidating these back together into a new or existing workspace, the two assumptions will not be doubled. Valsight detects that it is the same assumption and will calculate it accordingly, so that no further action has to be taken.

If you consolidate the assumptions into the original workspace, the workspace will still have the original assumption (i.e. inflation). In this case, the assumption has to be unchecked to prevent doubling, as the shared Scenarios will already carry the inflation in them.

Closing a workflow

Once all Workflow steps and all Scenarios have been submitted, reviewed (where necessary) and promoted to done, the Workflow can be completed by clicking the ‘Complete’ button in the header of its Configuration page or through the three-dot menu in the Workflow overview page. It can then be viewed under the ‘Completed’ tab.

Bildschirmfoto 2025-02-03 um 16.09.22.png

Stopping a Workflow: A Workflow that should not run to the end can be stopped instead of completed. Use the ‘Stop’ button and confirm ‘Are you sure you want to stop this workflow?’. The Workflow moves to ‘Canceled’ and joins the completed Workflows under the ‘Completed’ tab. Like a completed one, it can still be duplicated and reused later.

Duplicating a Workflow: ‘Duplicate’ in the three-dot menu of the Workflow overview opens the ‘Duplicate Workflow’ dialogue. You may give the copy its own version there, or leave the field empty and let Valsight generate one. The copy takes the name of the original with ‘ Copy’ appended and lands in ‘Draft’, so you can adjust its steps before starting it.

Deleting workflows and steps

Both deletions are gated on the state of the Workflow.

  • Deleting a Workflow is done from the three-dot menu in the Workflow overview. It is refused while the Workflow is active, with the message ‘This Workflow’s current status is ”…”. You cannot delete it.’ Complete or stop the Workflow first.
  • Deleting a step is only possible while the Workflow is still in ‘Draft’. Afterwards you get ‘This workflow’s current status is ”…”. You cannot delete any step inside.’ When the deletion is allowed, Valsight warns that deleting the step also removes it from the input list of every other step, so any dependency on it disappears with it.

A workspace taking part in an ongoing Workflow cannot be deleted either. The refusal names up to three of the blocking Workflows, plus a count of the remainder if there are more, and asks you to complete them first.

Email notifications

There are events that trigger e-mail notifications.

These events include:

  1. A new comment has been submitted on a step
  2. Data has been updated
  3. The status of a step changes (promoted or demoted)

The recipients are all users who hold a permission on one of the step’s states. The final state, ‘Done’, carries no permissions and is skipped.

If one of those states has no user or group assigned, every project admin, that is every holder of write permission on the project space, is notified in its place. Leaving step permissions blank mails all project admins rather than nobody.

The one who triggered the action will not be notified.

Mail goes out on a ten-minute cycle rather than immediately, and it is skipped for anyone who has ticked ‘Disable e-mail notifications’ on their user profile. If nobody on a Workflow ever receives these, e-mail is probably not switched on for your Valsight installation; ask your administrator.

Was this page helpful?