<img alt="" src="https://secure.mean8sigh.com/214862.png" style="display:none;">
Skip to content
English
More support Go to Customer Portal
Contact us
  • There are no suggestions because the search field is empty.

Configure Automations

Content

  • Overview
  • Pre-conditions
  • Steps
    • Create or Edit an Automation Rule
    • Test an Automation Rule
  • Supplementary Information
  • Notes

Overview

In a template or a document, you can create and configure automation rules to help streamline the workflows of the teams working on the applicable document(s).

This means that when an applicable document's trigger is met, an action automatically occurs for the document.

Triggers:

  • Specific stage is moved to
  • Deadline of specific stage is anticipated, met, or passed
  • Filled in metadata date is anticipated, met, or passed
  • Specified metadata field (so of any type) is updated
  • Approval change (approved, rejected, pending, added, or removed)

Conditions (what approvals and/or metadata have to be met for the execution to successfully fire):

  • Approvals for the current stage are:
    • approved
    • pending
    • rejected
    • operator:
      • all
      • equals
      • greater than
      • less than
      • is empty
  • Document fields are as specified (view in Steps section for a more comprehensive list)

Actions:

  • Send an email to recipients (specific in the steps section of this article)
  • Update metadata field*
  • Move to stage

After creating and configuring automation rules, you can run a test with any of them and manage them as well.

Lastly, you can review their executions through the audit logs.

1.3 configure rule

 

 

As your side may decide to create multiple automations per template, there can be more complexity in the overall picture, as 1 automation's action can be the trigger for another automation.

With this potential complexity in mind, it is highly recommended to test this scenario of multiple automations out with a test template and test documents with the scenarios your business has in mind, so as to identify best practices and configurations to aim towards, but also configurations to be wary/stay away from.

 

Also, if an automation has multiple actions, it may be best and simpler to split the automation into 2 and have each one have less actions in them, as more actions and possibly conditions in only 1 automation can create unneeded dependencies on early conditions and also undesirable scenarios where only 1 action is executed.

 

Pre-conditions

Configuring Automations on a Template/Document Level

  • System Level Permission:  [ 'System Administration' ] or [ 'Manage Automations' + ( 'Edit Documents' or 'Create Documents' or 'Document Manager' / 'Create Templates' )]
  • Document Level Permission: 'Owner', 'Editor', 'Reviewer', 'Viewer', or 'Read Released'

Configuring Automations on a Global Level

  • System Level Permission: [ 'System Administration' ] or [ 'Manage Automations'  + 'Document Manager']

Steps

Before proceeding with the core steps, there are 2 ways to configure an automation:

  • Template/document level - Narrow scope
  • Platform level - Wider scope, as this encompasses multiple elements (so across any combination of the document, template, or stage elements)

 

For the former, you have to go to the document or template (so you need direct access to it).

For the latter, you have to go to the Admin Panel module and navigate to the Automations tab.

 

Create or edit an automation rule:

  1. Click on the Screenshot 2024-01-29 at 19.47.05 icon in the top pane of the template/document.
  2. Click +Create automation (+New Automation) or on an existing automation rule to edit it.
  3. Enter name and description.
  4. Select 1 or both of the following on who can trigger this automation:
    1. User.
    2. Automation.
  5. (If starting in Admin Panel): Define the scope:
    1. First select the broad element (for 1st 2, you need direct access):
      1. Document
      2. Template
      3. Stage

    2. Then select the value(s) within that element.
  6. Select the trigger type:
    1. Metadata date:
      1. Specify the:
        1. Metadata date field.
        2. Timezone.
        3. Whether it's before, after, or at the metadata date:
          1. (If) before or after is selected:
            1. Time interval:
              1. 1 day.
              2. 1 week.
              3. 1 month.
              4. 3 months.
              5. Custom number with selectable time unit.
            2. Time of the day.
        4. (Optional): Click on the + symbol to add an or time sub-trigger relative to the first time sub-trigger.
    2. Stage change:
      1. Specify the stage(s)/state(s):
        1. Any.
        2. Draft.
        3. Custom.
        4. Release.
        5. Published.
        6. Non-material changes.
        7. Archived.
        8. Unarchived.
        9. New Version.
        10. New Amended Version.
    3. Stage deadline:
      1. Specify the:
        1.  Stage(s):
          1. Any.
          2. Draft.
          3. Custom.
          4. Release.
        2. Timezone.
        3. Whether it's before, after, or at the stage deadline:
          1. (If) before or after is selected:
              1. Time interval:
                1. 1 day.
                2. 1 week.
                3. 1 month.
                4. 3 months.
                5. Custom number with selectable time unit.
            2. Time of the day.
        4. (Optional): Click on the + symbol to add an or time sub-trigger relative to the first time sub-trigger.
      2. Note: Since a stage can be configured from the template level to not have a deadline, coordination with the template owner(s) configuring the stages is recommended to ensure alignment on whether to create this type of automation.
    4. Approval Change:
      1. Care is to be taken with this type of trigger, as it can be met several times. So it's worth considering whether to place any conditions (view further below for a better understanding of what it is and what options you have) after the trigger, and if so, which ones are appropriate so as to prevent excess executions.
      2. Select which types of approval changes:
        1. Status:
          1. Approved
          2. Rejected
          3. Pending*
        2. Other:
          1. Added
          2. Removed
    5. Metadata Change:
      1. Specify field to monitor change.
  7. (Optional) Select which condition(s) are to be met:
    1. Approval(s):
      1. Which operator to use:
        1. All:
          1. Pending
          2. Rejected
          3. Approved
        2. Equals: How many of the specified approval type are exactly needed for this condition to be met
          1. Pending
          2. Rejected
          3. Approved
        3. Greater Than: There has to be more of the specified approval type than this specified amount for this condition to be met.
        4. Less Than: There has to be less of the specified approval type than this specified amount for this condition to be met.
        5. Is Empty: There cannot be any type of approval for the current stage for this condition to be met.
    2. Metadata field(s):
      1. Checkbox:
        1. Equals ticked or not.
      2. Connection Picker:
        1. Operators:
          1. All
          2. Any
          3. None
          4. Is Empty
      3. Date:
        1. Operators:
          1. Exact
          2. Before
          3. After
          4. Between
          5. Calculate the specific time period before or after either the date the automation executes or the metadata's date.
      4. Link:
        1. Operators:
          1. Equals
          2. Contains
      5. Number:
        1. Operators:
          1. Equals
          2. Greater Than
          3. Less Than
          4. Is Empty
      6. Select:
        1. Operators:
          1. All
          2. Any
          3. None
          4. Is Empty
      7. Text:
        1. Operators:
          1. Equals
          2. Contains
      8. User Picker:
        1. Operators:
          1. All
          2. Any
          3. None
          4. Is Empty
      9. Note: Anyone of these fields can be set to dynamic values, in that they can be evaluated to match against values of other metadata fields of compatible types.

        Screenshot 2026-06-08 at 4.46.00 pm
        1. More to that, they can be set to a nested metadata field that is within a user picker field or a connection picker. * Dynamic Values in Automation Conditions
  8. Select what action is to be executed:
    1. Send email*:
      1. (Optional): Add CC and/or BCC fields.
      2.  For each recipient field, specify the type of recipient:
        1. Document role.
        2. Platform user.
        3. Platform user group.
        4. Email address.
        5. Approver type:
          1. All approvers
          2. Approvers - Approved
          3. Approvers - Pending
          4. Approvers - Rejected
        1. User picker field value*:
          1. For example: Give me users from these document metadata fields:
            • "Owner of the Document" user picker metadata
            • “SME” user picker metadata
            • etc...
      1. Subject.
      2. Body.
    2. Update Metadata:
      1. Search and select which field (custom and certain updatable system fields) to use.
      2. Select the applicable, relative action to take place on it:
        1. Set
        2. Add/Remove
        3. Calculate*
        4. Clear
      3. If applicable, choose what to set at/add in the Value field.
      4. Note: Anyone of these fields can be updated with dynamic values, in that they can use values of other metadata fields of compatible types. Update Metadata with Dynamic Values
        1. More to that, they can be set to a nested metadata field that is within a user picker field or a connection picker field. 
    3. Move to Stage/State*:
      1. Next Stage
      2. Previous Stage
      3. Draft
      4. Release
      5. Custom Stage
      6. Archive
      7. Unarchive
  1. (Optional): Toggle Enabled on/off from the top of the window to activate/deactivate the automation rule.
  2. Click Save.

Test an Automation Rule

  1. Open the Automation.
  2. Click on the document icon.
  3. Search and select the dummy document to perform the test run on.
    1. So keep in mind this actually executes the automation (by skipping the trigger) and thus any conditions and actions get run on it.
  4. Click Test Run.

Screenshot 2026-06-03 at 12.52.34 pmFlexible & Safe Test Run Pattern

A shareable link gets provided when running an automation, real or test execution, and when running a test, one can click into the linked run to immediately view the steps being taken real-time, and not have to refresh the page as it is updated real-time.

Screenshot 2026-06-05 at 3.24.04 pm

  • Use cases:
    • 1. Test Before Rollout: Create a new automation rule and test it against a dummy document first. Once you confirm the results are correct, enable the automation for all documents.
    • 2. 🔥 Fix One-Off Issues: If a critical document didn't process correctly due to format issues, manually trigger the automation rule on just that document instead of re-processing everything.
    • 3. Validate Rule Updates: Modify an existing automation rule (like changing approval routing logic) and run it against a sample document to preview the impact before rolling it out to all future documents.
    • 4. 🔥 Emergency Processing: When a document arrives outside normal processing times or in an unexpected format, manually execute the required automation on that specific document without affecting your automated workflow rules.

 

Supplementary Information

Email content

You can make use of any of the following smart values (standard and/or metadata) to personalize the content:

  • Standard smart values:
    • @document title (subject): will be replaced by the name of the relevant document.
    • @document (body): will be replaced by a clickable name of the relevant document.
    • @document version (subject & body): will be replaced by the latest version number of the relevant document.
    • @portal document title (subject): will be replaced by the name of the relevant document in the Policy Portal.
    • @portal document (body): will be replaced by the clickable name of the relevant document in the Policy Portal.
    • @portal version (subject & body): will be replaced by latest version number of the relevant document in the Policy Portal.
  • Metadata smart values:
    • @metadata name (subject & body): will be replaced by selected metadata field (both custom and system fields are available*)

Full screen mode

Click on the Screenshot 2024-01-29 at 18.33.54-1 icon to expand the automation rule window to full screen.

Notes

Real-time reconfiguration update

  • Configuring an automation rule reflects in real-time on to documents created from the template, so this type of enforcement is not through template releasing.

Scope

  • If the automation rule is being created within a document, its scope will only extend to that document.
  • Automation is to be viewed as a global entity - it will receive its own module in future iterations of the Clausematch platform.
    With this in mind, the scope will be more flexible, allowing the selection of exact documents to monitor without having to restrict the selection to a relatively-rigid option of a single document or documents from a specific template.

    Documents won't be the only objects to monitor, other objects such as Tasks will also be selectable.

Execution Subscription Limit

  • During our Beta phase for this functionality, you will have unlimited automation executions.
    After the Beta phase, you will have a number of included executions per month according to your tariff (with a specified cycle end date), which can be confirmed in the Automations tab of a template/document.

    • This is a paid module based on the number of executions per month.

      • If exceeded, the additional executions will count towards the monthly bill.
    • For more information on this subscription model, please contact your company's Customer Success Manager.

Metadata Date Notifications Migration

  • Metadata date notification settings before the deployment of 2024.1 to your platform have been automatically migrated to automation rules after 2024.1 deployment.
    Users will need to configure the recipient and content of the email.

UAT Whitelisting

  • Only whitelisted users on the platform will receive notifications based on Automation configurations.
    So you can safely test automations with your team without bothering other users.

Test an Automation rule

  • We will send 1 email with a list of recipients.
    • All recipients will be added to the BCC field (blind carbon copy - a copy of the message is sent to that recipient, but that name is not visible to other recipients of the message).
  • A test run will impact the execution counter.
  • When the automation scope is a specific document - then we will use this Document data to send test emails.
  • When the automation scope is Documents from the template - then we will use Template data to send test emails.

Metadata Smart Values

  • Subject does not allow selectable metadata such as links or multiline text fields.
  • If the metadata field has an empty value, was archived (or removed from the Document entity) or deleted from the platform - we will show [No Data].

User Picker Recipient

If the user picker field is removed from the platform or unassigned from the document entity, automation will no longer send emails to the users specified in this metadata field.

Update Metadata Field

This automatic setting or clearing would bypass the standard editing restriction, so even if the field is set as required or read-only (as set by its screen), the automation action will still take place.

  • However, like manual editing, system fields (e.g. release date) cannot be edited.

Approval Change

  • If an approver is added, it will only count as an Added event, not as a Pending event.
    • Pending can be caused not just by an approver being added, but also by other scenarios, such as:
      • The approver manually undoes their approve or reject decision.
      • Someone updates the document, which returns the approver to pending so they can review the changes again.
  • Pending is the default state when an approver is first added, or when they are moved back to ensure they re-review updates. That’s why we have three states: pending as the default, then approve or reject
  • The trigger operates at the document level and emits individual events for each approval change. So if there are multiple approvals present (e.g. 10 approvals on a document), each change (added, approved, rejected, removed) will activate the automation separately, potentially resulting in numerous actions.

Move to Stage Action

  • This action will bypass all stage restrictions, including:
    • Stages: Skip mandatory stages
    • Metadata: Skip required metadata fields
    • Approvals: Remove all rejected and pending approvals
    • Paragraphs: Remove paragraphs pending deletion
  • 🔥 Automations cannot move a document beyond the last stage in the workflow or before the first stage, so "Next" and "Previous" are only available where a stage exists.

Action: Calculate Metadata Date

  • Public holidays are not taken into consideration when selecting weekdays, so they will be counted as a weekday.

Update Metadata with Dynamic Values: Nested Fields

  • 1. Dynamic values are available only from compatible metadata types. For example, for date fields, you can use only other date fields' values, not values from other types. Text fields can use information from any field type.

  • 2. 🔥 When using nested fields, for example, from a User or Connection Pickers, only the first user or document is used to check its nested field value. If there are multiple values in the field, the others are ignored.

    • 2.1. If the selected nested field from a User Picker or Connection Picker is empty at runtime, the Update Metadata action is skipped, and the automation run is marked with an error indicating that the source field value is empty.