Access Control Best Practices

Your plugin calls APIs, reads data, and takes actions on behalf of users. Not every user should have access to every plugin. Access control is how you ensure the right people reach the right capabilities — and get a clear explanation when they don’t.

There are three strategies, and they aren’t mutually exclusive. Most production plugins combine at least two.

Secure the Underlying Action

This is not optional. Regardless of what you do at the plugin layer, the downstream system should enforce its own permissions. Moveworks supports this through connector-level authentication that ties actions to the requesting user’s identity.

OAuth 2.0 Authorization Code — The user grants consent to a third-party system. Moveworks runs a preflight check before the plugin executes. If the user hasn’t authorized the connector, the assistant prompts them to grant access. The plugin only runs after all required connectors are authorized.

JWT User Claims — The user’s identity is passed in JWT claims to the target system. Every API call executes as that user, preserving the target system’s audit trail and permission model.

RPA — When API integrations aren’t available, browser-based RPA logs into applications on behalf of the user, inheriting their session-level permissions.

DSL Launch Rules

Launch rules determine who can trigger a plugin. They are evaluated before the conversation starts, so there is zero latency impact on the user experience. If a user doesn’t match the rules, the reasoning engine won’t even consider the plugin when interpreting their request.

There are two modes:

• List Mode — Allow or deny specific email addresses. Good for testing or small, fixed audiences.
• Advanced Mode — Write DSL expressions that evaluate against user attributes. This is where attribute-based access control happens.

See Launch Permissions for the full configuration reference.

Sync Attributes for Fast Evaluation

DSL launch rules evaluate against the user record in Moveworks. If the attributes you need aren’t there yet, sync them from your identity provider through the Identity Gateway.

For example, if your organization tracks admin access eligibility in an Active Directory group:

user.custom_attributes.has_local_admin_access == true

user.department == "Engineering" AND user.custom_attributes.has_local_admin_access == true

This approach works well when:

• Latency matters — No API call happens at conversation time. The evaluation is instant.
• Attributes don’t change frequently — Group memberships, department, role, and license assignments are typically stable enough that syncing on a schedule is acceptable.
• You want to hide the plugin entirely — Users who don’t match the rules never see the plugin surface in the assistant. There’s no “you don’t have access” message because they never encounter it.

Common DSL Patterns

Runtime Eligibility Checks

Sometimes you can’t determine access from static attributes alone. The eligibility decision requires live data — a ServiceNow group membership, an approval status in a ticketing system, or a calculation that spans multiple systems. In these cases, you run the access check inside the conversation process at runtime.

The pattern is:

1. Action Activity — Call an API to check the user’s eligibility. Store the result in the data bank.
2. Decision Policy — Evaluate the result with DSL. Branch based on whether the user passes.
3. Content Activity (denial path) — If the user fails the check, display a clear explanation of why they don’t have access and what they can do next.
4. Continue (success path) — If the user passes, proceed with the plugin’s main flow.

Worked Example: Local Admin Access

A user asks to elevate their local admin privileges. Before running the provisioning action, the plugin needs to verify the user is eligible by checking their department, role, and whether they’ve completed the required security training — data that spans ServiceNow and a compliance system.

1
{
2
  "eligible": false,
3
  "reason": "Security training certification expired on 2025-11-15.",
4
  "next_step": "Complete the Security Awareness Training at https://training.example.com"
5
}

1
# Case 1: Eligible
2
data.eligibility.eligible == true
3
4
# Case 2: Not eligible
5
data.eligibility.eligible == false

When to Use Runtime Checks

Runtime eligibility checks add latency (one or more API calls before the main flow starts), so only use them when the data can’t be synced ahead of time:

• Data changes frequently — Real-time group memberships, approval statuses, or certification expirations.
• Data spans multiple systems — Eligibility requires joining data from ServiceNow, an HR system, and a compliance tool.
• Complex evaluation logic — Department hierarchy lookups, org-chart traversals, or custom business rules that don’t fit into a DSL expression.

Choosing the Right Strategy

Use this decision flow to pick your approach:

Most production plugins combine strategies:

• OAuth connector + DSL launch rule — The connector secures the action; the launch rule prevents unlicensed users from even starting the conversation.
• DSL launch rule + runtime check — The launch rule filters out obviously ineligible users fast; the runtime check handles edge cases that require live data.
• All three — OAuth secures the action, a launch rule gates on department/role, and a runtime check verifies training certification before executing.