Best Of

Author: Dave Waller, Principal Product Manager at Anaplan.

With the introduction of parallel tasks, Anaplan Workflow Advanced can bring additional efficiencies by parallelizing process steps that would ordinarily have to run in sequence. This functionality can help when using Anaplan Data Orchestrator to dramatically reduce the overall running time of data movement steps that would normally run sequentially:

However, parallel tasks can be applied to multi-stakeholder planning processes to accelerate planning, provide users with unique and tailored experiences, and drive collaborative engagement.

Examples of this may include a distributed approval process where a new CAPEX project requires commercial approval, marketing approval, and production approval before it can be progressed.

Each of these approvals can take place at the same time but, given the nature of each stakeholder, they all require a unique UX page and a unique set of instructions.

How-to guide

This guide assumes a working knowledge of Workflow, including the build and setup of:

1. End user triggered workflows
2. Line item driven decision steps
3. Skippable decision steps
4. Configuring decision steps with Boolean data writes
   

We’ll look at a scenario where end users are asked to create and submit new project proposals as part of a simple CAPEX use case. Once submitted, the project will be issued to three independent approvers who will each review the proposal based on their area of expertise. Once each approver has provided input and completed their review, we’ll consolidate those results and decide how best to proceed.

This article will guide you through the steps required to build this scenario and will provide two approaches to handling the consolidated review, one based on asking a final reviewer to analyze the previous approvals and make a final decision, and a second where a calculated Boolean will be examined to determine the overall approve/reject decision.

UX and model requirements

This example leverages several stakeholders who all need their own experiences building as UX pages. We will need:

1. An end user UX page to support the creation and submission of new promotions
2. A commercial review page to enable commercial review approval
3. A marketing review page to support addition of marketing milestones and approval of the project
4. A production review page to ensure product manufacturing are happy to approve
5. A final review page that helps a user in Operations review the approvals before adding a final approval, rejecting the project, or sending it back for rework
   

A number of model components are also required to support this scenario, starting with a list into which new projects will be added.

We will also define our approvers in a lookup module — this one is simple but could be extended to support a wider range of approvers so our projects can have them assigned based on model logic.

Image: A lookup module defining our approvers

We need a module to hold the details of our projects, and we’ll combine this with tracking data and approver details to keep things all in one place. We need to make sure this module is dimensioned by our projects list.

If we were to split this into multiple modules (one for project data and one for workflow data) then they both need to be dimensioned by the same projects list.

Image: The module to hold project data and workflow progress tracking information

This is how our projects module looks, with combined line items for defining our projects as well as tracking the progression of projects through our approval process:

We could also extend the scenario to only require commercial approval if the investment required for the project is greater than $25,000. This adds a simple formula to the “Commercial approver” line item:

We’ll use this in the rest of the example to show how a single, parallel step can be set to skip if it is no longer needed.

Workflow template

Our workflow template starts simple and includes a machine task that writes to a Boolean cell to identify the project has been submitted. The submission of projects is from an action button on a UX page, so our machine task has the “Projects” context set to “Sync to workflow”. This means that the project being reviewed will be automatically “passed into” the workflow and used to identify the specific data points to be written to with data write actions or used to look up assignees and approvers.

Once marked as submitted, we can progress projects to our three approvers.

Before we can add additional approval steps to run in parallel, we need to start the configuration of our commercial approval. We first need to provide a title and some instructions before selecting the appropriate page to use for the review. We also need to disable branching by toggling the “Continue workflow on rejection” switch to the “off” state.

Image: The first approval step with its initial configuration in place

Both branching and stopping a workflow on rejection are disabled when using decision steps in a parallel block. This ensures that no one part of the parallel block can prevent others from executing. Instead, you can leverage Boolean data writes and a final decision step to build your process, as we’ll do later.

We can now instruct Workflow to execute our additional approval steps in parallel by clicking the (+) button to the side of the step we’ve just added.

Image: This shows the first approval step added to the template with the (+) highlighted to add a parallel step

By selecting to add a second approval step you will see that both have now been wrapped in a “parallel block” to indicate that each step will be issued in parallel. We can click to add our third approval step to the parallel block before configuring each one.

Image: Three approval steps added in parallel

Our first approval, although all three will be triggered at the same time, is the commercial approval which we have pointed at our commercial review page and set to assign based on a line item.

When assigning the approval step using a line item, we can specify the user list formatted line item to use. In this case, we have selected our “Commercial approver” line item.

Our commercial approval step is also configured to write to the “Commercial approved” Boolean if it is approved, and the “Commercial rejected” Boolean if it is rejected. We have also set the “Projects” context to “Sync to workflow” so that the project being reviewed can be used to pinpoint the exact data points to read and write to.

Image: The Commercial approval step with “Skip on blank assignee” enabled

Finally, we want to set the approval step to “Skip on blank assignee” so that we can respect the model logic that drives whether an approval of this type is needed or not.

The other two approval steps can be configured in the same way, each using their own page and line items, remembering to sync the “Projects” context to workflow for each one.

Image: All three approval steps configured inside a parallel block

The final step in our simple approval process is to provide a final reviewer with an interface that lets them review each of the previous approvals before deciding on whether the project should be fully approved or not.

To complete this step, we’ve built our reviewer a bespoke UX page that provides details of the project as well as simple visualisations to indicate whether commercial, marketing, and production approvals were required or gained. This has involved the creation of some additional line items to support the required UX cards and conditional formatting and is something that can, if needed, be automated based on upcoming functionality.

A final decision step is added to the template and configured to point to the correct page, using a line item in a module to drive the approver. The module configuration has selected the “Final reviewer” line item for the user and the “Final review approved” / “Final review rejected” Booleans to track the outcome of the review. Again, the “Projects” context is set to “Sync to workflow” to ensure the correct data points are read and written to.

Image: The completed workflow template with parallel approval steps and a final review

This concludes the build of the workflow template. It can, of course, be enhanced with other steps like model actions to move approved projects into different modules for reporting, or line item driven notifications to project submitters. But, for the purposes of this example, we can leave the process template there.

Extending the workflow template with send-back loops and automated decisions

This process is particularly “one way” and doesn’t provide any mechanisms for contributors to make changes should their project be rejected. This can be addressed using the send-back functionality that will provide, in addition to “approve” and “reject”, a third option to allow the final reviewer to “send back” the submission to a previous step in the process.

By adding an initial “Edit project” task at the start of the process, carefully designed to be driven by a line item and set to “Skip on blank assignee” or an additional value-based decision step, it will be possible to create a “send back loop” from the final review. This will engage the original user with a notification allowing them to make changes based on commentary provided by the final reviewer before submitting their project back into the approval flow.

Image: An enhanced workflow template with a send-back loop from the final approval step along with an optional “edit project” step that is only used if work is sent back

If the need to bring in a final reviewer, to review the decisions made by domain expert approvers, is something you’d like to avoid in your process then you can automate this final decision step based on a Boolean value in a model.

Replacing the final approval step with a value-based decision, it’s possible to empower Workflow to review previous decisions and direct the flow of the process as required.

Image: Using a value-based decision step to automate the final approval decision

This will let you use any logic needed to analyse the previous approvals, adding appropriate weightings and rules, to determine whether the final decision is one of approved or rejected.

Workflow triggering

The process of creating new projects will be end user triggered and will make use of an action button on the main input page.

Image: An end user page for the creation of new projects

As a Page Builder we’ve selected to edit our page and then selected to edit the action card that contains our project creation form button.

We can now use the “Actions” tab to select new actions to add to the action card, including which Workflow templates we want them to be able to trigger.

The easiest way to track down the Workflow template, especially on an active tenant, is to provide a search keyword and then open the “Workflow templates” section to choose the relevant template (or templates of you want to provide access to more than one).

Finally, the Page Builder can use a combination of the “Manage” tab as well as the button styling options to create a clear call-to-action for end users. The Page Builder could even go a step further and select a “line item driver” for the button – a Boolean line item that controls whether the button is clickable or not. By adding this, builders can control, using model logic, whether the new project is in a state where it can be submitted into an approval workflow – are all fields populated, do the values fall within acceptable thresholds, etc.

Image: An end user page for the creation of new projects, with the page-level context selector for “Projects”

As our Workflow template steps have the “Projects” dimension set to “Sync to workflow”, each time a workflow is started using an action button on a page the selected item in the “Projects” context selector is passed into the workflow. This will then be used to control the specific data points workflow will look at to determine assignees, approvers and data writes.

Download step-by-step PDF

A comprehensive step-by-step walk-through of this process, with additional photo examples, can be downloaded here:

Questions? Leave a comment!

…………..

Related Workflow content:

• Experience expanded functionality and flexibility with Workflow Advanced
• Anaplan Workflow in action: Focused demo series
• Bulk processing with Workflow

Authors: Dave Waller, Principal Product Manager, and Abby Schutt Beckman (@AbbySB), Technical Training Program Lead at Anaplan.

Workflow Advanced is an additional capability in the platform that empowers businesses to visualize and automate processes with greater speed and confidence. At the time of this article, Workflow Advanced supports expanded branching of process flows, execution of multiple steps in parallel, sending back work to previous stages in the workflow, and querying of model values to automate decisions where human intervention isn’t needed.

Workflow Advanced features

Check out the below to learn more about the current features of Workflow Advanced. Note that, in addition to the technical considerations listed below, these features require that the tenant is enabled for Workflow Advanced, and only a Workflow Owner can leverage these steps in a workflow.

Parallel Steps

What it does: Allows multiple approvals to happen in parallel while providing different stakeholders with unique experiences.

Benefits: Approval steps can occur for multiple users at the same time, with the option to direct each stakeholder to a different page or provide them with different instructions.

Uses cases

• Approval of budget adjustment requests, where multiple department leads need to approve at the same time and need to be directed to department-specific UX pages to review the requests.
  
• When data needs to be moved to a series of modules simultaneously.
  

Technical considerations

• Parallel blocks — a collection of parallel steps — do not currently support branching. This means that if a decision step is added as the first step in a parallel block, the branching must be disabled before subsequent parallel steps may be added.
  
• If using ADO steps in the parallel block, there may be concurrency limits built into Anaplan Data Orchestrator that impact the workflow. If there are more ADO steps in the parallel block than what Anaplan Data Orchestrator can run in parallel, the steps will be queued to run at the earliest opportunity.

Branch and Reconnect

What it does: Allows steps to be added to both the approval and rejection branch of a decision steps, as well as the reconnection of a branch to another step to bring two branches together.

Benefits: Expands how approvals and rejections can be handled in a workflow, enabling more sophisticated workflows with complex branching logic — steps can be added to a rejection branch in Workflow Advanced and nested decision steps can also be used.

Use cases

• When a request is rejected by the L1 approver, the feature can be used to facilitate remediation steps and another L1 approval.
  
• If the same final step needs to occur regardless of which branch a workflow initially follows, the branches can be reconnected to show that the final step is the same.
  

Technical considerations

• If reconnecting to a parallel block, you must first collapse the block to reconnect a branch to the parallel block.

Send Back Loops

What it is: When a request reaches a decision step, the request can be sent back to a previous step in the workflow, providing a third response option for an approver (Approve, Reject, and Send Back).

Benefits: Provides additional flexibility with the standard decision step — if only small revisions are required for an item to move into an approvable state, the item can be sent back for revisions instead of requiring a new request be run through the entire approval workflow again.

Use cases

• Budget adjustment requests: The organization wants to allow the requester to make small revisions without moving the revised request through the entire approval process again.
  
• New job requisitions: It’s common for a manager submitting a job requisition to select the wrong cost center, resulting in Finance rejecting the request and asking the manager to fix and resubmit the request.

Technical considerations

• It’s best practice to use Dynamic Cell Access (DCA) with Anaplan Workflow to prevent the original user from editing an item after the workflow has started. If using Send Back Loops, a machine step to unset DCA will need to be included so the request can be revised.

Value-based decision steps

What it is: This feature operates similarly to a decision task, but instead of requiring a user to make the decision, a workflow owner can use a value-based decision step to query model data and make the decision based on the model value.

Benefits: Automates the decision process, reducing the time it takes to make the decision and allowing someone who would normally have been an approver to instead focus on other work.

Use cases

• Budget adjustment requests: The organization may require Legal Review for budget requests depending on the requesting department.
• Finance budget: Initiating action if variance exceeds a tolerable amount.
  

Technical considerations

• Value-based decision steps are based on a Boolean formatted line item; this line item must be created before it can be used in a value-based decision step.
  

Optimizing your use of the feature

• Pair nested value-based decision steps with IF THEN ELSE logic in the model.
• Use with send-back loops to handle the revised item slightly differently that if it were the first time the item was going through approval.
• Use with workflow scheduling to check if a Boolean line item is true on a set cadence (example: Check if variance has exceeded the allowable threshold on an hourly cadence).

Additional resources

• Workflow on Anapedia
  
• ACE Webinar recording: Learn about standard Workflow by watching the recording of this recent webinar.
  
• Workflow On-Demand Course on Academy: This course currently covers standard Workflow, with additional updated content coming soon.
  

Get enabled on Workflow Advanced

Workflow Advanced is separate from Workflow Standard and is tenant-specific, so in a multi-tenant environment the Workflow Advanced features only display on tenants that are enabled for Workflow Advanced. Speak with your Account Executive to learn more about Workflow Advanced.

Questions? Leave a comment!

Author: Miki Sato is a Product Manager, Product Management Team (Data Management) at Anaplan.

To drive accurate and agile planning, it’s critical to integrate actuals from SAP ERP systems (such as S/4HANA) into Anaplan in a structure aligned with its model framework.
This article compares three integration approaches — SAP Integration Suite, SAP Datasphere, and Anaplan Data Orchestrator (ADO) — and explores the strength and limitations of each tool — and why ADO may be the most aligned for planning-focused integration scenarios..

Note: This article reflects the perspective of the Anaplan product team and highlights why ADO is uniquely suited for planning-driven scenarios.

ADO (SAP Connector): Purpose-built for Anaplan planning integration

ADO is a no-code integration tool built with deep awareness of Anaplan's model structure — modules, lists, and hierarchies. It connects to SAP (e.g., S/4HANA) using OData v4 API and is optimized to transform incoming data into formats that Anaplan can directly consume. ADO enables business users to push data into Anaplan models directly from the UI.

Instead of building flows from scratch, users simply complete guided setup screens. Each step — from data connection to mapping — is configured in a structured form, and the visual flow is automatically rendered for reference. Only the necessary fields are shown, making it easy even for non-technical users to complete integration tasks.

Figure 1: ADO architecture and integration role

Figure 2: ADO’s flow visualization and parameter input UI

Only minimum parameters are required, and the configured flow is visualized automatically.

Key capabilities

• No-code GUI experience
   → Intuitive interface, no need for custom scripts or complex configuration
  
• Connects to SAP via OData v4
   → No code configuration for data extraction directly from the GUI
  
• Supports scheduling, delta loads, and visual lineage
   → Makes monitoring and operations easier and more transparent
  
• Built-in data catalog
   → Enables storage of transaction and master data as reusable assets for planning and consolidation purposes.

What’s next

The following items are part of our ADO roadmap for enhancing Anaplan–SAP integration:

• No native support for on-premise sources outside SAP (e.g., file servers)
   → Cloud options like S3 or Azure Blob are recommended
  
• Does not support real-time events or bidirectional sync
   → Cannot be triggered automatically by external events or systems

SAP Integration Suite: System-to-System API Hub

SAP Integration Suite is a robust iPaaS offering that supports cross-system integration, including non-SAP platforms. When integrating with Anaplan, the Anaplan Receiver Adapter enables external triggering of Import/Export Actions via Anaplan’s REST and Bulk APIs.

The tool allows for flexible flow design using its GUI, supporting event-based, scheduled, and conditional execution. While not optimized for Anaplan-specific structures, it excels in generalized data orchestration.

Note: The Anaplan Receiver Adapter is available only with an active SAP Integration Suite license.

Figure 3: SAP Integration Suite capabilities overview

Source: SAP SE, “What is SAP Integration Suite? © SAP SE. Image used for comparative explanation purposes.

Figure 4: Minimum flow setup and adapter parameters

Even a simple import requires manual setup of Action IDs and flow logic — making this approach suited for technical users only.

Key capabilities

• Connects to Anaplan APIs via official Adapter
  → Support both import and Export actions through Anaplan APIs
  
• Supports triggers, schedules, and complex flows
  → Enables complex orchestration logic and automation
  
• Rich connector catalog for SAP and non-SAP systems
  → Suitable for hybrid, multi-system integration environments
  

Limitations

• Requires technical configuration
   → Flow setup and maintenance are best handled by integration specialists
  
• No awareness of Anaplan model structure
   → Mapping is not aligned with Anaplan modules or hierarchies
  
• No built-in visual mapping
   → Data transformations require custom logic
  
• Separate license required
   → Adds cost for Anaplan-only integration scenarios
  
• More complex setup process
   → Multi-step design can slow down initial implementation
  

By contrast, Anaplan Data Orchestrator (ADO) delivers the same functionality through a fully no-code UI, making it significantly more accessible to business users.

SAP Datasphere: Persistent data layer for analytics

SAP Datasphere (successor to SAP Data Warehouse Cloud) is a cloud-native data fabric platform designed to centralize and harmonize SAP and external data for analytics and AI. It provides a persistent layer for modeling and enriching data—ideal for analytics, but not for real-time operational integration.

Unlike ADO or SAP Integration Suite, which focus on orchestrating and automating data movement and workflows across systems, Datasphere is optimized for batch and near-real-time analytical scenarios.

Figure 5: SAP Datasphere feature stack

Source: SAP whitepaper “Unleash the Power of Business Data with SAP Datasphere” © SAP SE. Image excerpted for product comparison purposes.

Figure 6: Visual modeling in SAP Datasphere

Source: SAP Developers Tutorial – “Create a Graphical View” © SAP SE. Image excerpted for illustrative/reference purposes.

Key capabilities

• Stores and transforms data from SAP and external sources
   → Centralized DWH with persistent storage
  
• Visual or SQL-based data flow builder
   → Build reusable transformation views
  
• Supports OData API and file-based access
   → Readable from external BI tools or systems
  

Limitations

• Not directly compatible with Anaplan actions or push
  
• Primarily designed for BI, not operational integration
   → Write-back and bidirectional sync require custom design

Feature comparison summary

The following table summarizes key differences across the three integration approaches. It provides a side-by-side view of capabilities, limitations, and ideal usage patterns — helping you assess which option best fits your planning, integration, or analytics needs.

Note: This comparison is based on current product capabilities as of July 2025.

Choosing the right tool based on use case

Each solution plays a different role, and in many cases, they complement one another. Here’s a high-level guide for selecting the right option:

*Note: SAP Datasphere does not connect directly with Anaplan. For scenarios involving Anaplan integration, it should be used in combination with SAP Integration Suite or a separate export workflow for API and metadata management.

Real-world integration examples: S/4HANA, SAC, and Anaplan

When organizations aim to visualize Anaplan data in SAP Analytics Cloud (SAC), here are three common integration scenarios:

1. S/4HANA → ADO → Anaplan
   Designed for structured data loads into Anaplan; ideal for planning scenarios. (Write-back may be possible in the future)
2. S/4HANA → SAP Integration Suite (Anaplan Receiver Adapter) → Anaplan
   Best for bidirectional use cases with complex logic and retry steps.
3. Anaplan → SAP Integration Suite → Datasphere → SAC
   Recommended for analytical reporting in SAC. Datasphere allows semantic modeling and metadata enrichment

Figure 7: End-to-End Integration Across Models, Systems, Semantics, and Analytics

Notes:

• ADO enables GUI-based integration with a single connector, whereas SAP Integration Suite and Datasphere typically require adapters on both the source and target systems.
• ADO cannot connect to Integration Suite via its SAP connector, as Integration Suite does not accept OData v4 requests from external systems.

The future of ADO: Evolving for planning integration

ADO will not only continue to evolve as a planning connector but is also positioned to become a central hub for managing external data connections across the enterprise.

Stay tuned as ADO continues to grow with your business.

Learn more

Anaplan Data Orchestrator

• Official Product Page
  
• How to Import Data from SAP (Anapedia)
  
• Example: SAP Connection Setup (Community)
  

SAP Integration Suite

• Official Product Page
  
• Feature Scope Description - SAP Integration Suite
  
• Anaplan Receiver Adapter (Official SAP Help)
  

SAP Datasphere

• Official Product Page
  
• Developer Mission: Get Started with SAP Datasphere
  
• Feature Scope Description - SAP Datasphere

……………

Other articles from Miki:

• How Anaplan powers reliable reporting
• ADO: Moving beyond data hubs to planning-aware integration
• Connected Planning with Salesforce x Anaplan

Author: Dave Waller, Principal Product Manager at Anaplan.

Using certain modeling and page build techniques, it is possible to embed images across your UX apps in a way that provides alternate text for users who may be visually impaired or who may be using assistive technologies to announce on-screen elements.

This article will guide you through the techniques needed to ensure images are provided with ALT text (or aria-labels), ensure model building best practice, and delivering end user experiences that are more in line with the WCAG2.1 accessibility requirements.

Defining a system module

Anaplan system modules are centralized modules typically used for the storage of static values that other modules, line items and calculations can refer to. This is seen as a best practice when building modules and provides a single location of the management and maintenance of global variables and values.

(For a micro-lesson on creating system modules, see this video.)

We can use a system module to define core properties of the images or UX pages will use.

Being sure to use any agreed naming conventions, create a new list to hold the list of images you wish to store, and a new module dimensioned by your images list and two line items, one to hold a URL (formatted as text/link) and another to hold default ALT text (formatted as text/general).

This module can be simplified, removing the capability for custom ALT text in the future, by giving it just a single text/link formatted line item told both URL and ALT text. Or, we can add a third line item to make things more sophisticated and store some baseline ALT text in our system module too. The following example shows all these options.

Once in place, the system module can be used to both embed images directly into UX pages or can be used as a base to refer to when adding images into other modules using formulas such as:

IF forecast value <= threshold THEN

  SYS MOD images.url[SELECT: SYS LIST images.red light]

ELSE

  SYS MOD images.url[SELECT: SYS LIST images.green light]

Using images from the asset library

Anaplan provides an internal asset store, offering centralized and secure storage for images used in Anaplan UX pages. The easiest way to use these images inside pages is to link them directly from the asset library, however this approach does not provide adequate ALT text when pages are published.

Instead, builders should expose the URL of the images in the asset library and use these to populate their system modules.

Once added to the asset library, images can be selected to expose a “Copy URL” button. This can be used to retrieve the URL for the uploaded image, ready to be added to the system module.

https://us1a.app.anaplan.com/a/mms-mms/media/customers/8a81b01166eee1af0166f7bde931314e/images/~

6ceb7ccf7c6549cf92fb36ec1208baac.png

Generating dynamic ALT text

Line items defined as text/link use a simple markdown format to define both display text and URL within a single data point.

[Display text]https://url.to.use/for-the-image.png

We can use simple concatenation formulas to build this value dynamically, crafting ALT text for the image that is aware of other model values and therefore more assistive to end users.

(Resource: Anapedia - Operators and constants)

If we want to display a red light image if a forecast value is less than the defined threshold, and a green light image if it’s higher, but also provide guidance on why the value is invalid, we can use a concatenating formula like:

IF forecast <= threshold THEN

  “[A red light image indicating that your forecast of “ &

  forecast & “ is invalid as it must be at least “ &

  threshold & “.]” & SYS MOD images.url[SELECT: SYS LIST

  images.red light]

ELSE

  “[A green light image indicating that your forecast of “ &

  forecast & “ is acceptable.]” & SYS MOD images.url[SELECT:

  SYS LIST images.green light]

This would, assuming the forecast ($900) is lower than the threshold ($1,000), generate a text/link formatted line item value of:

[A red light image indicating that your forecast of 900 is 
invalid as it must be at least 1000.]https://.../red-light.png

This approach can also be extracted out a little by using an additional line item, here in the forecast module, to define our ALT text but only if we need it. If no custom ALT text is provided then we can fall back to that defined in the system module:

IF Forecast.forecast <= Forecast.threshold THEN

  IF ISBLANK(Forecast.ALT text) THEN

    SYS MOD images.combined[SELECT: SYS LIST images.red light

  ELSE

    “[“ & Forecast.ALT text & “]” & SYS MOD images.url

    [SELECT: SYS LIST images.red light

ELSE

  ...

This simple addition checks to see if a custom ALT text value exists in the forecast module. If it does, it gets combined with the image URL to create a custom text/link line item value. If it’s blank, then we fall back to the “combined” value defined in the system module.

In complex cases, care should be taken to try to minimize the number of cells used when concatenating values into a single text string. The use of “&” can introduce slowness to some calculations if multiple cells, modules and line items are used to generate a single value.

You can view an indication of the calculation complexity of a concatenated line item using the “modules” > “line items” view and the “calculation effort” value for your line items.

Adding images to UX pages

Line item driven image URLs can be added to UX pages with the use of image cards. When adding an image card, be sure to select “line item” as the image source.

Select the module and the line item to use to define the image — this can be your system module if your images are static, such as logos or horizontal rules.

Depending on how your system list is defined, you may initially get an error message that your image is not valid. This is because we are yet to specify which image we want to reference. We do this using the “context” tab in the right-hand panel.

By opening the section for “SYS LIST images” we need to make a few changes:

• We need to disable “sync with page” to ensure that the page builder defines the image
• We need to select the correct image for the “page context” value
• We need to make sure that “show on card” is set to “off” to ensure that end users can’t change the image that’s displayed

These changes will display the line item driven image inside the image card and will implement the correct ALT text for the image in both the builder and published modes.

Adding images to UX grids

When adding grids of data to a UX page, they will display all text/link formatted line items as text values by default.

Using the “line item image settings” section at the bottom of the right-hand panel you can decide which line items should render as images rather than text. Using our system module, the only line item defined as text/link is the “combined” line item that defines both the url and ALT text.

Enabling this line item to display as an image has an immediate effect on the preview of the grid, now showing an image in the cell rather than text.

Once enabled as image display, we can also tailor the size of the image if needed.

The published page now includes the grid images, at the specified size, along with appropriate ALT text.

Questions? Leave a comment!

……………

Also by Dave: End user triggering of workflow processes.

Author: Dave Waller, Principal Product Manager at Anaplan.

With the release of action button workflow triggers, customers have been able to apply Workflow to a raft of new use cases and business processes. End users are now able to instigate processes directly from their dashboards and UX pages, opening up the possibility for processes like:

• Creating budget requests and submitting them for approval
  
• Identifying incorrect commission statements and raising disputes
  
• Logging CAPEX projects and submitting into a formalised review process
  
• Creating a new headcount request and passing it to HR for action
  
• And more
  

In many of these scenarios, a user will create a new item (or collection of items) that will become the “subject” of the workflow process — the specific budget request to be approved, for instance. This helps all stakeholders in the process clearly identify the things to be reviewed or approved and helps ensure accuracy by logging views of data and visualizations down to the specific item.

Depending on the type of process to be supported, the number of submissions expected, and the level of customization an implementation team is happy to build, there are a range of approaches that can be taken to deliver these scenarios with Workflow.

✅ This article will cover the creation and submission of a single item into a workflow process.

How-to Guide

The most straightforward approach, and with the most native support built into the Workflow tools, allows for the creation of individual items and their submission into a formal process. It combines UX board pages, UX forms, UX action buttons, and standard workflow steps to create a new item and pass it through a series of approval steps.

We’ll look at a scenario where end users are asked create new investment opportunities before submitting them into a two-tier approval process. We’ll make one level of approval conditional based on the data the user has input, and we’ll circle back round at the end and alert the user if their opportunity is approved.

In addition to the list we’ll use to store our opportunities we need a few extra items building in our model.

The investment opportunities list:

The investment approvers module:

Plus any additional modules to hold opportunity data, in my example I have a range of properties, including a list formatted line item to hold the opportunity type which can be used to further refine our approvers, and even a time-based forecast of income vs expenditure. They key aspect of this, for our example at least, is a line item to hold the investment amount, and the data needed for the workflow to execute.

The Investment data module with line items to be used by Workflow:

It is critical that this module is dimensioned by the list that holds our investment opportunities as we’ll need this to be able to look up the correct line items our process will need. It also contains a number of these line items:

An additional forecast module used to enhance the visual aspect of the demo:

With the model components in place, we now need two UX pages to support our workflow: a page for end users to create and populate investment opportunities, and a second page for approvers to review the submitted data.

They key thing to remember with both pages is that our opportunities list needs to be used as a page-level context selector.

Doing this enables Workflow to do three things:

1. When the approval process is triggered by the end user, the selected item in this list is detected and past into the process as the “subject” for later steps.
2. Use this when looking up data in connected modules (assignees, approvers, etc) and when writing to connect Boolean line items.
3. When later steps in the process are loaded for approvers (or other users in general) the page selector is automatically set to the correct item, ensuring all downstream users see exactly the right slice of model data.

The UX page used by end users to add new investment opportunities:

The page for end users contains a form to support the creation of new investment opportunities.

The UX form used to create a new opportunity:

One of the great features with UX forms, especially when the list being added to is a page-level context selector, is that when the new item is inserted into the list it is automatically selected at the page level. We can leverage this when we trigger our approval workflow, as we can have this selected item picked up automatically as the “subject” of our process.

The UX page used by reviewers to approve opportunities:

Note that both pages have the opportunities list as a page-level context selector but these have been set to “label” so they provide clarity to the user as to which one is selected, but removes the ability to select a different one. When our approver lands on the page to complete their review, there will be no question they are viewing the correct item.

Page-level context selector settings to prevent users from changing the opportunity their task is based on:

When new opportunities are submitted, our workflow will perform a number of tasks:

1. Mark the opportunity as submitted
2. Issue the L1 approval
3. If L1 approval is successful, issue the L2 approval
4. If the L2 approval is successful, mark the opportunity as ready to have funds released
5. Notify the original submitter

The overall workflow template:

Step 1: a machine task to mark the opportunity as “submitted”:

The first step in the workflow updates our Submitted line item to indicate the opportunity has been submitted into an approval flow. This uses a standard Data Write Machine task with the Investment Data module selected and the Submitted line item identified.

You will also note that the setting for the Investment Opportunities dimension is set to Synced to workflow. This means that this value will be synced to the value passed into the workflow from the triggering page.

The Investment Data module with the targeted intersection highlighted:

If “The Old School Hall” is selected on the page, this will be used to identify the specific data point to update — the intersection of The Old School Hall and Submitted in the Investment Data module.

Step 2: a decision task for the L1 approval

The first approval step is a decision task with our approver page selected and some appropriate instructions for the approver provided in the task details. As we want the approver to be specified using our Investment Data module, we’ve selected to Assign to users from a line item in a module.

The configuration of Step 2, showing how it connects to the underlying module:

By editing the line item selection, we can specify the exact intersection in our module that we want workflow to look at to determine who our approver should be. The Investment Data module is selected, and the L1 approver line item is chosen as the user list formatted line item to define our first approver. We can also select the L1 approved Boolean line item to be automatically ticked when the item is approved. We can optionally set a L1 rejected Boolean line item should the item be rejected — I have chosen to omit this for now.

Again, to specify the exact data intersections to use, we have configured the Investment Opportunities to Sync to workflow so whichever selected opportunity is passed into the workflow will be used to identify our intersection.

The configuration of Step 2, showing available approval options:

The final part of configuring the L1 approval is to define how we want to handle rejections. We know that no matter what, all opportunities need some form of L1 approval, so we have switched off the option to Skip on blank approver. If for whatever reason, our line item to define our approver is blank, the workflow will now pause and alert an administrator.

We know that we want to stop our approval process if the L1 approver rejects the opportunity, so we have Continue workflow on rejection switched off, and we always want the reject option to show to our approvers, so we also have Hide reject switched off.

Step 3: a decision task for L2 approval

Our L2 approval is very similar to the L1 approval — it links to our approval UX page and has some appropriate instructions added for our L2 approvers.

It’s also configured to Assign to users from a line item in a module with the Investment Data module selected. This time we’ve chosen the L2 approver line item to define the approver and the L2 approved Boolean line item to be set when the approval is made. We’ve also set the Investment Opportunities dimension to Sync to workflow, as with our other steps, to allow Workflow to identify the correct intersections to use in the module.

Where this step differs is with its final configuration options. We want to provide approvers the ability to reject, and we want to stop the workflow should a rejection take place, so we have Continue workflow on rejection and Hide reject both switched off.

We know, however, that only certain opportunities are going to require an L2 approval with those that don’t being given a BLANK value for the L2 approver line item. This means we can set Skip on blank approver to on so that if Workflow gets to this stage and encounters a blank line item, the step is skipped, and the process continues down the “approved” path.

‼️ Note that the L2 approved Boolean will not be set in this instance as no explicit approval took place.

Step 4: a machine task to mark the opportunity as “approved”

Based on how we’ve configured previous steps in the workflow, the configuration of the machine task that updates an opportunity as “fully approved” is relatively simple. We’ve used a Data Write machine task to update the Scheduled for fund release Boolean line item in the Investment Data module, with the specific Investment Opportunity set to Synced to workflow.

Step 5: a notification step to send a final confirmation to the opportunity owner

The final step in the process is to close the loop and inform the submitter (or the owner of the investment opportunity) that their submission has been fully approved. We can do that with a simple notification step at the end of our template.

A message is provided, and the step is configured to Assign to users from a line item in a module.

As these steps don’t use a UX page, where we would normally identify the workspace and model, we need to provide that data in the configuration of the step. Once a workspace and model are set, we can define the line item to use.

The configuration of step 5, showing how it connects to the underlying module:

We’ve again selected the Investment data module and the Investment owner user list formatted line item. As with our other steps, we’ve also set the Investment Opportunities dimension to Synced to workflow so that Workflow can identify the specific data intersection needed to get the details of the user to be notified.

Summary

This simple workflow template combines the flexibility of the UX with the structured and defined business processes to support end-user-led planning. It removes the need for end users to tick Boolean checkboxes, trigger email links, or run model actions. It provides clear notifications and calls-to-action for approvers and uses model logic to influence the path of the process. Task handover is fast and automatic, with the potential to drive down the time it takes to submit data and pass it through an approval flow.

However, this process (and the workflow functionality that supports it) is designed for the submission and approval of single items. Users wishing to create and submit multiple opportunities must do each one in turn — create → submit, create → submit, etc.

It’s also worth considering the approver experience when looking at supporting a process like this. Each new submission will generate a new notification for approvers — if there are 50 new opportunities raised each day, and only a single L1 approver, then that approver will receive 50 emails a day that need to be managed and actioned.

Questions? Leave a comment!