Documentation
DocumentationDeveloperAcademyCommunitySupportLogin
Start typing to search…

Access Account Configuration Overview

Moveworks Access Account provides users with a secure channel to self-service their login issues.

📘

Important Configuration Note

To configure redirect messages or links for Access Account features (password reset, account unlock, MFA reset), navigate to Moveworks Setup > AI Assistant > Plugins and configure the Access Account deflection plugins. These will take precedence over any legacy portal mode settings configured here.

Overview

Access Account is composed of these key features:

  • Unlock Account — Alert users when they're locked out of their accounts and help them regain access.
  • Reset Password — Help users with self-service password resets.
  • Reset MFA — Help users initiate MFA resets when a mobile device is lost or replaced.
  • Proactive Password Expiry Notifications — Notify users when their passwords are about to expire.

Some features can only be activated by a user messaging the bot (MFA Reset) or by a system event occurring, while others can be activated by both (Unlock Account).

Supported Identity Systems

The table below shows which Access Account features are supported by each identity management system:

Identity SystemUnlock AccountReset PasswordReset MFA
Okta✅✅✅
Active Directory✅❌❌
OneLogin✅❌✅
Ping Identity❌❌✅
📘

Proactive Password Expiry Notifications work with ANY identity system as long as the password_expires field is ingested in the identity mapper configuration.

Unlock Account

Configure settings for notifying users when their accounts are locked and helping them regain access.

Enable account unlock

Enables the unlock account skill. Requires Enable polling of account lockouts. Also, note that this plugin does not accept a DSL rule. Any user filtering must be done in the Proactive Reachout Filter.

Type: DSL Rule

Reference: Unlock Account Documentation

Proactive Reachout Filter

Rule for whether to notify a user if their account is detected as being locked out. For more information, refer to the Moveworks DSL Reference.

Type: DSL Rule Context: User data

Enable polling of account lockouts

Enables the bot to poll your identity system to identify accounts that were locked out. Only enable this if your bot is configured for proactive unlock account notifications to prevent unnecessary polling of your identity system.

Note: This feature only enables the polling of locked accounts and does not enable the notification itself.

Type: DSL Rule Context: User data

Reset MFA

Configure settings for helping users reset their Multi-Factor Authentication factors.

Enable MFA reset

Enables the MFA reset skill.

Type: DSL Rule Context: User data

Reference: MFA Reset Documentation

Enable MFA reset via ticket interception

Enables the bot to offer the MFA reset skill via ticket interception. Requires Enable MFA Reset.

Type: DSL Rule Context: User data

Login Path (full URL or a relative path)

Link which users can follow to set up a new MFA factor. Can be a full URL or a relative path (ex: '/enduser/settings'). If a relative path is provided, the full URL will be constructed from the instance URL defined in the Connector config of the targeted MFA integration.

Type: URL or relative path Example: /enduser/settings or https://company.okta.com/enduser/settings

Reset Mode

The manner in which users are able to reset their MFA factors if they are found to have multiple.

Options:

  • User can choose to reset all factors or a single factor — Most flexible option, allows users to choose their reset strategy
  • User can only reset one factor at a time — More controlled approach, requires users to select a specific factor
  • User can choose to reset all factors from a single provider or across all providers — Provider-grouped reset option

Proactive Password Expiry Notifications

Notify users before their passwords expire. Works with any identity system (Active Directory, Okta, Azure AD, OneLogin, etc.).

Setup Required

Step 1: Add User Password Meta Info Processor

In your User Ingestion Configuration, add the User Password Meta Info Processor to the processing pipeline. This processor calculates password expiration dates from the ingested timestamp fields.

Step 2: Configure Identity Mapper

Map password fields from your identity system using one of these patterns:

Option 1: Direct expiration date (recommended if available)
"password_meta_info.password_expires": "$TIMECONV(expirationField, NULL, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)"

Option 2: Last changed date (requires Password Lifespan setting)
"password_meta_info.password_last_changed": "$TIMECONV(lastChangedField, NULL, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)"

Field Name (left side): Must be password_meta_info.password_expires or password_meta_info.password_last_changed
Field Value (right side): Reference to your identity system's actual field wrapped in $TIMECONV()

Proactive Reachout Filter

DSL rule to filter which users receive notifications. Has access to all ingested user fields.

Example:
user.password_meta_info.password_expires != None AND user.account_type != "service"

Enable proactive password expiry notifications

Type: Boolean

When enabled, users receive notifications at 14, 7, 3, 1, and 0 days before expiration.

Requirements:

  • User Password Meta Info Processor must be added
  • Password data must be mapped in Identity Mapper (see Setup Required above)

Advanced Settings

Password Lifespan

Type: Duration (in seconds)
Example: 2592000 (30 days), 7776000 (90 days)

When to use: Only required if using password_last_changed without password_expires. The processor calculates:
password_last_changed + password_lifespan = password_expires

Must match your organization's actual password policy configured in the identity system.

Time before sending proactive password expiry notifications

Type: Duration (in seconds)
Default: 1209600 (14 days)

How early to start sending notifications before password expiration.

How It Works

  1. Daily Processing: System fetches user data daily from identity system
  2. Processor Calculation: User Password Meta Info Processor calculates expiration dates
  3. Filtering: Proactive Reachout Filter determines eligible users
  4. Notification Schedule: Users receive reminders at 14, 7, 3, 1, and 0 days before expiration

Identity System Examples

Active Directory (LDAP)

Using computed expiry field (recommended):
"password_meta_info.password_expires": "$TIMECONV($[msDS-UserPasswordExpiryTimeComputed][0], LDAP, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)"

Using last changed + lifespan:
"password_meta_info.password_last_changed": "$TIMECONV(pwdLastSet[0], LDAP, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)" Then configure Password Lifespan to match your AD Group Policy password policy.

Okta

"password_meta_info.password_last_changed": "$TIMECONV(passwordChanged, NULL, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)" Then configure Password Lifespan to match your Okta password policy settings.

Note: Okta does not directly expose password expiration dates - only last changed date.

Azure AD (Microsoft Graph)

Azure AD password expiration must be accessed via custom select fields in the API request:

"password_meta_info.password_last_changed": "$TIMECONV(lastPasswordChangeDateTime, NULL, %Y-%m-%dT%H:%M:%SZ, NULL, NULL, FALSE)" Then configure Password Lifespan to match your Azure AD password policy.

Note: Ensure your Graph API request includes $select=lastPasswordChangeDateTime to retrieve this field.

Bidding Configuration

Bidding configurations control which identity management system handles specific requests when multiple connectors are configured. This is particularly important in multi-system environments where different applications or services may be managed by different identity providers.

Account Bidding Config

This setting manages the bidding rules for utterances related to forgotten passwords and locked accounts.

Select connector

Defines the Identity Management (IDM) system to execute necessary API actions.

Type: Connector selection Examples: "okta", "onelogin", or "active_directory"

Controlled Entities

A collection of entity names that help in understanding the ownership of systems. If the same entity is controlled by two systems, it is assigned to the system that references it first. An empty field renders standard entities based on the type of system selected.

Type: List of entity names

Example: If "okta" controls the "slack_password" entity and a user requests a password reset for Slack, the Access Account flow initiates based on the Okta integration.

Controlled Entity Sets

A list of Entity sets which serve as shortcuts for standard groupings of entities.

Type: List of entity set names Available Entity Sets:

  • duo - Duo Security entities
  • ms_auth - Microsoft Authenticator entities
  • okta - Okta entities
  • onelogin - OneLogin entities
  • ping - Ping Identity entities
  • rsa - RSA SecurID entities

MFA Bidding Config

This setting controls the bidding rules for utterances related to Multi-Factor Authentication (MFA).

Select connector

Specifies the IDM system to perform necessary API actions for MFA related utterances.

Type: Connector selection Examples: "okta", "duo", "onelogin", or "ping"

Controlled Entities

Lists entity names to identify what system a particular entity belongs to. If an entity is controlled by two systems, it is assigned to the system that references it first. Leaving this field blank prompts us to use the standard set of entities for the selected system.

Type: List of entity names

Example: If an entity like "slack_mfa" is controlled by "okta", any MFA issues in Slack would trigger the relevant flow within the Okta system.

Controlled Entity Sets

Pre-defined groups of entities that act as shortcuts for commonly grouped entities.

Type: List of entity set names Available Entity Sets:

  • duo - Duo Security entities
  • ms_auth - Microsoft Authenticator entities
  • okta - Okta entities
  • onelogin - OneLogin entities
  • ping - Ping Identity entities
  • rsa - RSA SecurID entities

Configuration Notes

DSL Rules

Many Access Account features use DSL (Domain-Specific Language) rules for fine-grained control over when features are enabled or triggered. These rules allow you to:

  • Filter users based on attributes (department, location, role, etc.)
  • Determine when notifications should be sent
  • Control feature availability based on user context

For detailed information on writing DSL rules, refer to the Moveworks DSL Reference.

Duration Values

Duration fields accept values in seconds. Common conversions:

  • 1 hour = 3,600 seconds
  • 1 day = 86,400 seconds
  • 7 days = 604,800 seconds
  • 14 days = 1,209,600 seconds
  • 30 days = 2,592,000 seconds
  • 90 days = 7,776,000 seconds

Integration Requirements

Access Account features require properly configured connectors to identity management systems. Ensure your connector is configured in Moveworks Setup > Connectors before enabling Access Account features.

Bidding Configuration Use Cases

Bidding configuration is essential when:

  1. Multiple Identity Systems - Your organization uses different identity providers for different applications (e.g., Okta for SaaS apps, Active Directory for on-premise systems)
  2. System Migration - You're transitioning from one identity provider to another and need to handle requests for both systems
  3. Departmental Systems - Different departments use different identity management solutions

Example Scenario: Your organization uses Okta for most applications but Active Directory for legacy systems. Configure bidding so that:

  • Okta controls entities like slack_password, salesforce_password, zoom_password
  • Active Directory controls entities like vpn_password, windows_password, legacy_app_password

When a user says "reset my Slack password," Okta handles it. When they say "reset my VPN password," Active Directory handles it.

Additional Resources

Updated about 9 hours ago