Skip to main content
In the Workflows section of the m3ter Console you can quickly create, build, and configure m3sh Workflows to fulfill your operational requirements. This topic introduces the key concepts and options you’ll make use of when creating, managing, running, and reviewing your Workflows:

​
Understanding m3sh Workflows

A m3sh Workflow implements an automated routine started by a trigger. Once triggered, the Workflow runs through an ordered sequence of steps, where each step performs a function. In more complex Workflows, a step might perform a sub-workflow which itself consists of one or more functions. A toolkit of various function types are available for building your Workflows. These functions allow you to introduce variables into the Workflow “state” to hold data values. In subsequent steps, you can use functions to manipulate those state variables, create new variables, or by using logic functions build in decision gates to determine which of alternate paths specific Workflow runs will take. In brief:
  • All Workflows have access to the payload of the Workflow trigger. The trigger will be either an Event on which a Notification rule is based or an Incoming Webhook.
  • API functions allow you to load data via an API call to various external systems or to m3ter, and you can choose the variable name that the API response is stored under in the Workflow state.
  • Data management functions allow you to manipulate the variables you’ve introduced or even create new ones from what is already held in the Workflow state set using Transformations.
  • Logic functions allow you to alter how Workflow runs based on variables within the Workflow state branch based on some IF check, start looping over a list/array, and so on.
When preparing to design and build a Workflow to automate your operational requirements, it’s important therefore to think in terms of how the “state” set of variables will be created and initialized, modified, added to, or used to determine alternate paths through each of the ordered sequence of steps performed when the Workflow runs.

​
Common Workflow Applications

There are two main areas where m3sh Workflows are designed to fulfill your operational requirements for implementing automated processes:

​
Interoperability - Data Exchange across Systems

A core operational requirement Workflows fulfill is for designing and implementing data integration routines to control the exchange of data between your m3ter Organization and your external systems:
  • Outbound from m3ter Organization into an external system.
  • Inbound from an external system into your m3ter Organization.
m3sh Workflows are not restricted to simply pulling data from one system - say m3ter - and transferring it to another system - say your external Accounts Receivable system - but give you wide scope to control data transfer and exchange to meet your specific use cases. For example:
  • When a new data item is created in one system, create a corresponding predefined data item in another system.
  • Pull a data item from the source system and incorporate intermediate steps:
    • To apply a calculation to the data value before loading it into the target system data item.
    • To apply conditional logic and only load the source data item into the target system if the condition is met.

​
m3ter - Enhance and Extend

From the outset, a core objective was for m3sh Workflow automation to extend and strengthen the value proposition of the m3ter platform:
  • Can be directly hooked into m3ter configuration and used to complement and strengthen the platform’s capacity to address and fulfill evolving operational billing and analytical needs.
  • Deploy m3sh triggers for automated update and management of key billing entities in response to defined end-customer Account Events, such as Balance depletion or Contract expiry.
For example, you might offer a pricing model to your end customers that gives them a free sign-up credit balance and bills their Account using an introductory credit Plan. When this credit is exhausted, you want to automatically switch their Account in m3ter to use a different full contract Plan for billing. You could build a Workflow triggered each time the credit balance on an Account is updated, checks the balance amount, and when the balance credit has reached zero switches the Plan used for the Account.

​
Workflows - Types and Triggers

m3sh Workflows fall into two types based on the type of trigger used:
Workflow Managed Templates. You can create Workflows from templates,which are designed and managed by the platform to meet specific common operational use cases. See the following Workflow Managed Templates section for more details.

​
Event Notification Workflows

This type of Workflow uses m3ter Event-based Notification rules as a trigger:
  • In m3ter you can create and configure Notification rules that you want to use as Workflow triggers. You must then link the Notification rule to the Workflow by adding it to the Workflow as a trigger.
  • When an Event occurs on which the Notification rule is based and any conditions built into the rule are satisfied, it causes the Notification to fire and the Workflow is triggered.
  • The Notification’s payload is the data returned by the system Event on which it is based and this data is then injected into the Workflow state and made available using an event prefix to reference it in your Workflow functions:
    • For example, suppose you want to trigger a Workflow using a Notification rule based on the billing.balanceamount.updated system Event, and this Notification will fire and trigger the Workflow only when this Event occurs and the new.amount field for the Balance updated Event equals zero.
    • You can then add functions to create Workflow steps that reference other fields in the Notification’s payload. Continuing the example - you might want to update the end date of a m3ter AccountPlan to match the date on which the billing.balanceamount.updated Event occurred for a zero Balance reached. You can then lookup in the Workflow state the value of event.new.dtLastModified and use it to update an Account Plan’s end date.
See Creating, Managing, and Reviewing Notifications.

​
Incoming Webhook Workflows

This type of Workflow uses an Incoming Webhook as a trigger. You can set up these triggers for Workflows you want to use to enable interoperability between m3ter and your external systems:
  • In your external system, you must first set up a Webhook destination that you’ll use to send any data payloads to for syncing with your m3ter data.
  • You can then set up Incoming Webhook Credentials in m3ter for authenticating Incoming Webhooks with Workflows as destinations and allowing them to act as Workflow triggers. When you add a webhook trigger to a Workflow, you can then select the relevant Incoming Webhook Credential.
  • When your external system sends a data payload to the Webhook, the Workflow is triggered.
How this works Every m3ter Organization has a provisioned inbound Webhook endpoint. External systems can POST to this URL to trigger a Workflow. Only POST requests are supported. The request body is injected into the Workflow state under the body prefix. For example, if the Webhook is called with:
Then body.accountId and body.amount are available in the Workflow state. See Creating Incoming Webhook Credentials.
Scheduled Workflow Triggers? Scheduled Triggers are on the roadmap. The current workaround is to use an external scheduler, such as AWS EventBridge or a cronjob, to call the Inbound Webhook URL on the required schedule.

​
Workflow Functions

A wide toolkit of functions is available for use when building your Workflows. As you add functions, the Workflow Builder environment offers you many usability features to facilitate and streamline common Workflow tasks:
  • Drag-and-drop functions to quickly create Workflow steps.
  • Validation of functions is performed as you add them, and incomplete functions are clearly flagged as invalid.
  • Edit function forms list any required fields and prerequisites, such as Credentials or Transformations that a function must reference.
  • Easily insert, detach, and re-attach functions to quickly rearrange a Workflow step sequence, and avoid having to delete and re-add functions.
  • Create global parameters to use when configuring multiple functions requiring a common parameter, such as Credentials or Transformation parameter. When these require an update, you can make a single update for the global parameter.
Workflow Builder! Before you attempt to create a Workflow and add functions to it, we strongly recommend that you review Getting to Know the Workflow Builder and familiarize yourself with the Workflows build and management environment.

​
Function Types

The following table gives a summary of the three different types of functions available when building m3sh Workflows:

​
Global Parameters

You can set up four types of Global parameters to use in your Workflows when adding and configuring functions:
  • Credentials
  • Transformation
  • Workflow
  • Outgoing webhook
See Working with Global Parameters for more details.

​
Setting Up Workflow Prerequisites

As you begin to add functions to create Workflow steps, you’ll need to set up prerequisites for some functions:
  • Transformations. m3ter Transformations allow you to customize the conversion of data as it flows into or out of the m3ter system. A Transformation defines a one-way data mapping from one specific data type to another. See the following Creating and Managing Transformations topic.
  • Credentials. For data integration with external systems, you’ll need to set up Credentials for authentication with specific systems. See Creating and Managing Integration Credentials for more details.
  • m3ter Credentials. For functions that will call m3ter API endpoints, you’ll need to set up m3ter Service User Credentials. See Service Authentication.
  • Incoming Webhook Credentials. If you create an Incoming Webhook Workflow, you’ll need to set up credentials for the incoming webhook to be able to authenticate with the Workflow as destination and gain access to the Workflow to act as its trigger.

​
Exporting and Importing Workflows

If you’ve built and published a Workflow and want to use the Workflow as the basis for another Workflow - by adapting the current Workflow to serve a different operational use case - you can export the Workflow and import it as a new one. See Exporting and Importing Workflows for more details.

​
Workflow Managed Templates

You can create Workflows using pre-built templates, which are designed to fulfill specific automation use cases. Workflow templates are managed by the platform to ensure reliability and consistency. When you create a Workflow from a template, editing is restricted and you won’t be able to alter the main design flow by adding or removing functions. You will be able to edit functions to provide required parameters to suit the particular Workflow instance such as adding any required credentials. If you want to use a managed Workflow template in a customized and unmanaged way that avoids editing restrictions, there are two options:
  • Branch from template. When you create a Workflow, select a managed template as the starting point and maintain full control over it’s functions. No editing restrictions are imposed and you’ll be able to add new functions, remove functions, or modify functions. However, your Workflow will no longer benefit from updates made for future versions of the original platform managed template. See Branching from a Managed Template.
  • Export and import. You can create a Workflow instance from a managed template, export the instance, and then import it as a regular Workflow. See Exporting and Importing Workflows.
Workflow Managed Templates - Notes:
  • Available Templates. Currently one Workflow managed template is available: Submit measurements from S3 source with SNS trigger. More are expected soon.
  • Worked Example. To follow a worked example of how to create and configure a Workflow based on a managed template, see Utilizing Workflow Managed Templates.

​
Workflow Testing and Troubleshooting

The Workflow Builder offers options to support and facilitate both troubleshooting published Workflows and testing Draft versions before publishing them:
More Details! Please review the Testing and Troubleshooting Workflows topic for more details on how to work with these options.

​
Reviewing Workflow Runs

Workflows runs are logged by date and time and listed in the m3ter Console. When troubleshooting Workflows runs, you can quickly open a run and review detailed run logs on a step-by-step basis.

​
Enabling Traffic Forwarding

If you’ve deployed a Published Workflow to production and you’re now in the process of updating a Draft version of the Workflow for additional functionality, you can enable traffic-forwarding to the Draft version. This will temporarily switch traffic so that the Draft version of the Workflow will be triggered instead of the Published version allowing you to test your Draft updates.

​
Replaying Workflows Runs

You can replay a Workflow run using the same Event Notification or Incoming Webhook trigger responsible for the original run. Replayed runs are clearly identified and this capability is especially useful when testing new Workflow designs or troubleshooting failures in existing Workflows without having to re-trigger runs from external systems.

​
Accessing m3sh Workflows

​
Access Levels

  • By default all Organizations have read-only access to m3sh Workflows, both in the Console and through API endpoints. This means all users can view existing workflows and their execution history.
  • To create, edit, or delete m3sh Workflows, your Organization must have the m3sh feature flag enabled.
Important: Enabling Write Access. If you are interested in have m3sh Workflows feature flag enabled for your Organization, please reach out to your m3ter contact to discuss and agree commercial terms.

​
Console Access

To access Workflows in the m3ter Console, select m3sh in the main navigation menu: M3sh Main Nav1 The Workflows page opens:
  • Any existing Workflows created for your Organization are listed and you can open these in the Workflow Builder.
  • You can create new Workflows, create managed Workflows, or import a Workflow.
In the m3sh section, you can open pages to create and manage other automation features:
  • Transformations
  • Notification rules

​
API Endpoints

A full list of endpoints for m3sh Workflows is available in the Integrations section of our API Reference documentation.

​
Constraints and Limitations

Constraints and limitations are imposed on the deployment and running of Workflows, as detailed in the following table:

​
FAQs

​
Can m3sh Workflows be triggered on a schedule?

Scheduled triggers are on the m3sh roadmap. The current workaround is to use an external scheduler, such as AWS Eventbridge or a Cronjob, to call the Inbound Webhook URL and to trigger a Workflow’s on the required schedued.

​
Can m3sh Workflows be triggered manually?

No.

​
Do m3sh Workflows require credentials?

Workflows themselves don’t require credentials. But some functions, particularly those that imply HTTP requests to either external systems or the m3ter system, require credentials to be provided. These can be created as Integration Credentials - where the credential format will depend on the system - and then shared across several functions in the Workflow or across several workflows.

​
Can m3sh Workflows call other m3sh Workflows?

Yes, however the max depth is 1. You can have a Workflow invoking another Workflow, but the invoked Workflow itself cannot then invoke a Workflow. If this is attempted, the execution will immediately fail. This guardrail prevents infinite loop execution cycles, and explosive Workflow run log growth.

​
Is m3sh Workflow execution limited in any way?

Yes - see the above Constraints and Limits section.