Configure Native Approvals Workflows
What are Native Approvals?
Native approvals are workflows designed to automate the approval process for tasks and functions within a system. They are ingrained in the functioning of the system and follow its inherent rules and procedures.
Native approvals in Moveworks provide a sequence of validations for different actions or requests, such as permissions to a resource or additions to a distribution list. These processes can be tailored according to specific roles, tasks, and predefined conditions.
They expedite approval requests by categorizing them based on certain parameters and directing each to an appropriate authority for approval. By employing conditions and rules, these approval workflows filter and sort requests to eliminate unnecessary steps and find the most efficient path to resolution.
Default Native Approval Workflows in Moveworks
Moveworks offers a variety of built-in, or 'default', native approval workflows, acting as standard templates for common use cases. They represent the foundational elements that can be customized to form flexible and adaptive approval workflows fitting an organization's unique approval process needs.
- APP_ADMIN: The Application Administrator's approval is necessary to carry out certain functions.
- MANAGER: This type of approval requires the consent of the individual's Manager.
- AUTO_APPROVE: Here, tasks or requests are automatically approved, bypassing the need for an approving authority.
- STANDARD_TRUST_MODEL: This workflow triggers if the requestor is their manager or their role matches predetermined roles. If these conditions aren't met, it falls back to require the Distribution List Owner's approval.
- STANDARD_WITH_FALLBACK_TO_MANAGER: Similar to Standard Trust Model, but when the initial conditions aren't satisfied, approval falls back to the Manager.
- MOST_RESTRICTIVE_TRUST_MODEL: A workflow that operates under stricter conditions for automatic approval. If not met, it reverts to require the Distributor List Owner's consent.
- MOST_RESTRICTIVE_WITH_FALLBACK_TO_MANAGER: A stricter workflow that requires the Manager's approval as a fallback when initial conditions aren't fulfilled.
- LEAST_RESTRICTIVE_TRUST_MODEL: This workflow operates under more flexible approval criteria. When conditions aren't met, approval from the Distribution List Owner is sought.
- GSUITE_OPEN_OR_OWNER: Specific to G-Suite requests, this workflow requires the consent of the Owner, or the group must be open for the action to go through.
- AUTO_APPROVE_FULL_TIME_ELSE_MANAGER: If a full-time user makes a request, it's approved automatically. Otherwise, it calls for approval from the Manager.
- AUTO_APPROVE_FULL_TIME_ELSE_APP_ADMIN: Similar to the previous workflow, but if the requestor is not a full-time user, approval from the App admin is required.
- APP_ADMIN_THEN_MANAGER: A two-step approval process. First, the App Admin needs to approve. If approved, the workflow moves to require the Manager's approval.
- MANAGER_THEN_DL_OWNER_WITH_FALLBACK_TO_AUTO_APPROVE: A process where Manager approval is sought first, followed by the DL Owner. If these aren't fulfilled, it falls back to automatic approval.
- MANAGER_THEN_DL_OWNER : A sequential workflow that first seeks the Manager's approval, then progresses to the DL Owner.
- ADD_TO_DL_APPROVAL: This workflow refers to getting approval to be added to a Distribution List. It typically requires the consent of the most restrictive role, falling back to the manager's approval if necessary.
- REMOVE_FROM_DL_APPROVAL: This pertains to getting approval to be removed from a Distribution List. The process mirrors the ADD_TO_DL_APPROVAL workflow.
- CREATE_DL_APPROVAL: This workflow automatically approves the creation of a Distribution List.
- GET_DL_MANAGER_APPROVAL: Here, the approval from the Manager of the Distribution List is required.
- MOST_RESTRICTIVE_WITH_FALLBACK_TO_DL_MANAGER: A stricter approval process that moves from requiring DL owner approval to DL Manager approval if initial conditions are not met.
Adding Custom Approval Workflows
Moveworks enables businesses to streamline and tailor their approval workflows to meet organizational requirements. Through native approval logic and flexible customizations, Moveworks can handle diverse approval scenarios. This document provides a detailed overview of how to write custom approval workflows using Moveworks' native approval syntax. It covers various approval models, logic types, and the syntax components that make it all possible. We also provide practical examples to illustrate how these workflows can be configured
To create a custom approval workflow:
-
Navigate to Moveworks Native Approvals: In Moveworks Setup, navigate to Moveworks Native Approvals on the left hand menu under the Access Management grouping
-
Create a new approval by clicking 'create'
-
Name the Custom Approval Workflow: Provide a unique identifier for your custom workflow.
-
Input the Workflow Expression: The workflow expression is written using a JSON block. Refer to the JSON Documentation below for guidelines on crafting this expression effectively.
-
Add the new approval flow to the software - Navigate to Access Software > Software Catalog and edit the software you would like to add the custom approval to. Choose 'Custom Approval Workflow' under 'Provisioning Method' and use the dropdown under 'Custom Approval Workflow' to select the new approval you created.
1. Approval Expressions and Logic Types
Approval From Approval Group
This model sends approval requests to a specific group of users based on their role or a predefined external ID. It allows for parallel approval with a configurable number of approvers. Approval group approvals are supported for Okta, Azure, and GSuite. For thi
Example:
{
"parallel_group_expression": {
"group": {
"external_id": "00gq0p1j6jGsb0ZCO2p8",
"integration_id": "aee48223-5f11-4e26-b0f9-e33f935bacc1"
},
"max_to_ask": 2,
"number_required": 1,
"role": "MEMBER"
}
}
Note: integration_id refers to the Moveworks internal ID for the System the group lives in (I.e. Okta or Azure). Please reach out to Moveworks Support for the integration ID for the system you need to configure group approvals with.
external_id refers to the approver group ID in the external system such as Okta or Azure.
2. Sequential Approval
Sequential approval ensures that approval requests are delivered in a defined order. Approvals are sent to users one by one in a specific sequence. Once the first approver approves, the second approver will receive the approval notification.
Example:
{
"sequential_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "example@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "example2@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "example3@moveworks.ai"
}
}
]
}
}
Example: Manager then App Admin:
{
"sequential_expression": {
"expressions": [
{
"manager_expression": {}
},
{
"app_admin_expression": {}
}
]
}
}
3. Conditional Approval with Fallback
This model evaluates conditions (e.g., user email or role) and routes the approval request accordingly. If the condition isn’t met, the request can be passed to another predefined approval workflow.
Example:
{
"condition_expression": {
"clauses": [
{
"condition": {
"rule_v2": "requestor.email_addr.$LOWERCASE() == \"example1@moveworks.ai\".$LOWERCASE()"
},
"expression": {
"user_constant_expression": {
"user": "approver@moveworks.ai"
}
}
},
{
"condition": {
"rule_v2": "requestor.email_addr.$LOWERCASE() == \"example2@moveworks.ai\".$LOWERCASE()"
},
"expression": {
"user_constant_expression": {
"user": "approver2@moveworks.ai"
}
}
}
],
"default_expression": {
"referenced_expression": {
"name": "NAME_OF_ANOTHER_APPROVAL_MODEL"
}
}
}
}
4. Conditional Role-Based Approval
Conditions can be based on roles or user attributes such as department or level. This allows for dynamic approval workflows based on the role selected by the user.
The role_canonical_name_to_provision should match the 'Unique role name' configured in the software entry in Moveworks Setup.
Example:
{
"condition_expression": {
"clauses": [
{
"condition": {
"rule_v2": "approval_request.approvable_entity.app_entity.role_canonical_name_to_provision.$LOWERCASE() == \"role_name\".$LOWERCASE()"
},
"expression": {
"sequential_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "example@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "example1@moveworks.ai"
}
}
]
}
}
},
{
"condition": {
"rule_v2": "approval_request.approvable_entity.app_entity.role_canonical_name_to_provision.$LOWERCASE() == \"role_name_2\".$LOWERCASE()"
},
"expression": {
"condition_expression": {
"clauses": [
{
"condition": {
"rule_v2": "$LOWERCASE((users_requested_for[0].role)) == \"cse\".$LOWERCASE()"
},
"expression": {
"auto_approve_expression": {}
}
},
{
"condition": {
"rule_v2": "$LOWERCASE((users_requested_for[0].role)) == \"csm\".$LOWERCASE()"
},
"expression": {
"parallel_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "approver1@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "approver2@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "approver3@moveworks.ai"
}
}
],
"number_required": 1
}
}
}
],
"default_expression": {
"auto_deny_expression": {}
}
}
}
}
],
"default_expression": {
"auto_deny_expression": {}
}
}
}
5. Approval Based on Work Status
Approvals can be routed based on a user's work status (e.g., Full-time, Contractor, etc.).
Example:
{
"condition_expression": {
"clauses": [
{
"condition": {
"rule_v2": "users_requested_for[0].work_status == \"FULL_TIME\""
},
"expression": {
"app_admin_expression": {}
}
}
],
"default_expression": {
"sequential_expression": {
"expressions": [
{
"manager_expression": {}
},
{
"app_admin_expression": {}
}
]
}
}
}
}
6. Approval Based on Custom and User Attributes
This model uses custom attributes like seniority, department, or custom roles to determine the approval path. For example, if a user’s seniority level is above a certain threshold, they might bypass some approval steps.
Example:
{
"condition_expression": {
"clauses": [
{
"condition": {
"rule_v2": "users_requested_for[0].custom_attributes.seniority_level IN [\"Director\", \"VP\", \"SVP\", \"EVP\"]"
},
"expression": {
"auto_approve_expression": {}
}
}
],
"default_expression": {
"sequential_expression": {
"expressions": [
{
"manager_expression": {}
},
{
"parallel_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "vp_leader@example.com"
}
},
{
"user_constant_expression": {
"user": "svp_leader@example.com"
}
}
],
"number_required": 1
}
}
]
}
}
}
}
General Syntax Breakdown
Here’s a quick reference for understanding the different syntax components in Moveworks approval models:
1. user_constant_expression
user_constant_expressionThis expression specifies an individual user for approval, identified by their email.
Example:
{
"user_constant_expression": {
"user": "example@moveworks.ai"
}
}
2. sequential_expression
sequential_expressionThis sends approval requests one after the other in a defined sequence.
Example:
{
"sequential_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "approver1@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "approver2@moveworks.ai"
}
}
]
}
}
3. parallel_expression
parallel_expressionThis sends approval requests to multiple users simultaneously. The number_required field specifies how many approvals are needed.
Example:
{
"parallel_expression": {
"expressions": [
{
"user_constant_expression": {
"user": "approver1@moveworks.ai"
}
},
{
"user_constant_expression": {
"user": "approver2@moveworks.ai"
}
}
],
"number_required": 1
}
}
4. auto_approve_expression
auto_approve_expressionThis automatically approves the request without requiring intervention.
Example:
{
"auto_approve_expression": {}
}
5. auto_deny_expression
auto_deny_expressionThis automatically denies the request without requiring intervention.
Example:
{
"auto_deny_expression": {}
}
6. referenced_expression
referenced_expressionThis references another approval model.
Example:
{
"referenced_expression": {
"name": "other_approval_m"
}
}
7. condition_expression and rule_v2
condition_expression and rule_v2Conditions allow the routing of requests based on user attributes, custom attributes, or request-specific data. rule_v2 evaluates expressions that can include operations on data, such as comparing values or checking membership in a list.
Conditions Based on User Attributes
As referenced in the examples above, you can create conditional approval flows based on user data. To see what data is populated for users, navigate to User Identity > Ingested Users.
Moveworks allows for external system user level data to a predefined list of supported attributes:
first_name
last_name
email_addr
role
department
manager_email
full_name
employee_id
cost_center_id
cost_center_name
country_code
timezone
region
city
state
work_status
To update or check the mapping of these fields navigate to User Identity > Ingest Users. Edit the configuration and navigate to page 2 and select 'Advanced Mode'. Field mappings will be pulled from the system marked as 'Is Primary Source' unless they are specified in the 'Override User Profile Fields' section or are a system specific ID such as user_id_info.user_itsm_id_info.
Please note, any changes to attribute mapping will take effect following the next user ingestion cycle.
Custom Attributes Configuration
Custom attributes allow for highly tailored approval models based on organizational-specific attributes, such as department, role, or seniority. To configure custom attributes for your organization, you must work with the Moveworks implementation team. Contact support to initiate custom attribute configurations.
Updated 18 days ago