---
title: End-User Access Control
excerpt: ''
deprecated: false
hidden: false
metadata:
  title: ''
  description: ''
  robots: index
next:
  description: ''
---
When building plugins, consider these three access control strategies:

## Strategy 1: Access Control by System Authentication

This strategy uses the access control policies defined by your external system to enforce access control. There are three tiers of system-based authentication integrations.

**Option 1: Using JWT User Claims**

The user's information is passed in your [JWT claims](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-claims). Your business system then executes any APIs as if they were executed by that user. This preserves the audit trail & permissions of the target user.

See instructions for [JWT Auth here](/docs/jwt-auth).

**Option 2: Using OAuth 2.0 Authorization Code Authentication**

This is similar to Option 1 (JWT User Claims), but involves a user step to grant permission before the bot can take action.

See instructions for [OAuth 2.0 Authorization Code here](/docs/oauth-20-authorization-code).

**Option 3: Using RPA Tools**

When the proper integration APIs are not available with your tools, browser-based RPA is a good fallback. Since RPA logs into applications **on behalf of users** the keystrokes & button clicks they execute follow that user’s permissions.

## Strategy 2: Access Control by Design

A common scenario is ensuring users only see _their_ records. In this design approach, you rely on data attributes on the record to determine if the user should have access to it.

| Record Type     | Example System         | User                 |
| --------------- | ---------------------- | -------------------- |
| Ticket          | ITSM (e.g. ServiceNow) | “Caller” / “Watcher” |
| Account         | CRM (e.g. Salesforce)  | “Owner”              |
| Job Application | ATS (e.g. Greenhouse)  | “Hiring Manager”     |
| PTO Balance     | HCM (e.g. Workday)     | “Employee”           |

In this scenario, you

1. **Pass the user's information into your API** based on your HTTP action's [data bank](/docs/http-action-data-bank)
2. **Query the record of interest** that the user wants to see or modify. You may filter records by the user’s account.
3. **Check the data attributes of that record** (Find the watcher/caller/hiring manager)
4. **Throw an error if the user shouldn’t have privileges**

This requires you to “mirror” the access control logic of your downstream system in your process/experience APIs.

## Strategy 3: Access Control In Moveworks (aka. Launch Rules)

After publishing a use case, you can tailor its availability to specific audiences using "rules". This is especially useful when users lack licenses, allowing you to define a default access control policy.

![](https://files.readme.io/3c12fff198a37a461d7ceb4ba5e14ce8d168c9150df3d52f436c9f1194ce13b5-image.png)

You can pull user attributes from any system to craft these rules. See [our user identity documentation](/docs/user-identity) for more details.