> ## Documentation Index
> Fetch the complete documentation index at: https://docs.accessowl.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Templates

> Create and configure Access Templates: applications, permissions, auto-assignment rules, attribute priority, and the simulator.

Access Templates define which applications and permissions a new hire receives based on their job role. This page is the configuration reference for templates: creating them, setting up auto-assignment rules, attribute priority, and the simulator.

[Org Admins and HR](/general/roles) manage templates in the [admin interface](https://app.accessowl.io/access_templates).

<Info>For how templates are selected during a manual onboarding (Slack or web), see [User Onboarding](/guides/onboarding-offboarding/onboarding). For fully automated onboarding via your HRIS, including the recommended template structure, see [Zero Touch Onboarding](/guides/onboarding-offboarding/zero-touch-onboarding).</Info>

***

## Creating an Access Template

1. Go to [Settings → Templates](https://app.accessowl.io/access_templates).
2. Click **New Access Template**.
3. Enter a **Title** (e.g., "Sales Manager") and **Description**.
4. Add applications and permissions:
   * Click **Add Application** and select from your managed applications.
   * Add **Resources** (repositories, vaults, channels) and their **Permissions**.
5. Click **Save**.

<Info>Applications must be a managed application to appear in the dropdown.</Info>

### Duplicating a Template

From the [Access Templates list](https://app.accessowl.io/access_templates), use **Duplicate** to copy an existing template, including its applications, permissions, and auto-assignment settings. Then rename and adjust the copy.

<Tip>Use duplication to set up a near-identical template for a similar role, instead of rebuilding it from scratch.</Tip>

***

## Configuring Applications and Permissions

Each template can include multiple applications. For each application, you define:

* **Resources**: Items within an application (GitHub repositories, 1Password vaults, Slack channels).
* **Permissions**: Permission levels for each resource (Admin, Member, Read-only).

### Single-select vs Multi-select

Some resources allow only one permission (e.g., a single role per application), while others allow multiple selections (e.g., membership in several teams).

<Warning>Changes to a template apply immediately to all future onboardings. Existing user access is not affected.</Warning>

***

## Auto-Assignment Rules (HRIS)

<Info>Auto-assignment rules only apply to onboardings via an [HRIS integration](/integrations/all/HRIS). For manual onboardings via Slack or web, templates are selected directly by the person handling the onboarding.</Info>

Auto-assignment rules determine which templates apply to a new hire based on their HRIS attributes. When a user is onboarded via an HRIS integration and their attributes match the rules, the template is applied automatically. This enables [Zero Touch Onboarding](/guides/onboarding-offboarding/zero-touch-onboarding).

### Supported Attributes

* **Department** - e.g., "Engineering", "Sales"
* **Employment Type** - e.g. Full-time, part-time, contractor
* **Role** - e.g. "Senior Software Engineer"
* **Location** - e.g. "Berlin"
* **Teams** - e.g. "Payment", "Claims"
* **Direct Reports** - whether the user is a manager (has direct reports)

<Info>**Direct Reports** checks whether anyone lists this person as their manager. The manager relationship is pulled from your HRIS and can be overridden in AccessOwl. Use *Is Not Empty* to match managers only - for example, to give people managers access to HR tools. *Is Empty* matches non-managers.</Info>

### Rule Conditions

Each rule has three parts:

| Component     | Description                                                                                   |
| ------------- | --------------------------------------------------------------------------------------------- |
| **Attribute** | The HRIS field to match                                                                       |
| **Operator**  | How to compare: *Equals*, *Not Equals*, *Contains*, *Does not contain*, *Is set*, *Is one of* |
| **Value**     | The value to match against (not used for *Is set*)                                            |

You can add multiple conditions to a template. **All conditions must match** for the template to apply.

<Tip>Use "Contains" for job titles to catch variations. `Role contains "Engineer"` matches "Software Engineer", "Senior Engineer", and "Engineering Manager".</Tip>

<Tip>Use "Is one of" to match multiple values within a single condition. For example, `Department is one of (Data, Engineering)` applies the template to both departments without creating separate templates for each.</Tip>

### Enabling Auto-Assignment

1. Open an access template and go to the **Auto Assignment** tab.
2. Toggle **Auto-assign this template** to enable.
3. Add one or more conditions.
4. Click **Save**.

When disabled, the template can still be selected manually during onboarding but won't be applied automatically via HRIS.

<Tip>For the recommended way to structure your templates (Baseline + Department + Role + Location) and a full example rule setup, see [Zero Touch Onboarding](/guides/onboarding-offboarding/zero-touch-onboarding#best-practices-for-zero-touch-onboarding).</Tip>

***

## Attribute Priority (HRIS)

<Info>Attribute priority only affects automatic template matching via HRIS. For manual onboardings, you select the templates directly.</Info>

When multiple templates match a user's HRIS attributes, AccessOwl uses **attribute priority** to resolve conflicting permissions.

### How It Works

Templates are grouped by which attribute triggered the match. Higher-priority attributes override lower-priority ones for conflicting permissions:

* **Single-select permissions**: The template from the higher-priority attribute wins.
* **Multi-select permissions**: Entitlements are combined from all matching templates.

**Example**: If "Team" has higher priority than "Department", a team-specific template overrides a department-wide template when both match.

### Configuring Attribute Order

1. On the Access Templates page, click **Attribute Priority**.
2. Drag and drop to reorder. The top attribute has the highest priority.

***

## Testing with the Simulator (HRIS)

<Info>The simulator tests auto-assignment rules for HRIS onboardings. It does not apply to manual template selection via Slack or web.</Info>

Use the **Automation Simulator** to preview which templates would apply to a hypothetical user before actual onboarding.

1. On the Access Templates page, click **Test Automation**.
2. Enter user attributes (Department, Role, Team, etc.).
3. Click **Simulate**.

The results show:

* **Matched Templates**: Which templates would apply, grouped by the triggering attribute.
* **Final Access Grants**: The complete list of applications and permissions.

<Warning>An "Undefined order" warning indicates multiple templates matched at the same priority level. Adjust your rules or attribute priority to resolve conflicts.</Warning>

***

## FAQ

<AccordionGroup>
  <Accordion title="Can I assign a template to an active user?">
    No. Access Templates apply only during an onboarding (Slack, web, or HRIS). For a user who is already active, create the equivalent access requests instead:

    * Ask [Claude in Slack](/guides/ai/claude-in-slack) in plain English, for example "give Mike Carter the same 1Password vaults as Michael Scott".
    * Use [bulk access requests via the API](/api-reference/access-requests/create-bulk).

    Both run through your normal approval flow.
  </Accordion>

  <Accordion title="What happens when an employee is added to the HRIS?">
    Templates whose auto-assignment rules match the employee's attributes are applied automatically, and access is provisioned on the start date. See [Zero Touch Onboarding](/guides/onboarding-offboarding/zero-touch-onboarding#how-it-works) for the full workflow.
  </Accordion>

  <Accordion title="Can I use the same application in multiple templates?">
    Yes. When multiple templates match (via HRIS auto-assignment) and include the same application, permissions are resolved based on attribute priority. Single-select permissions use the highest-priority template; multi-select permissions are combined.
  </Accordion>

  <Accordion title="What happens when a permission conflict cannot be resolved?">
    If multiple templates define conflicting permissions at the same priority level and the conflict cannot be automatically resolved, AccessOwl creates a **custom request** for that application during onboarding. The application admin receives a Slack DM to manually define the final permissions. The onboarding task for that application shows a "Specifying Access" status until the app admin resolves it.

    **To avoid conflicts:**

    * Make sure the same application does not appear in multiple templates with different permission levels at the same priority.
    * If you need a baseline template alongside department-specific templates, use different HRIS attributes for each (e.g., "Employment Type" for the baseline template and "Department" for department-specific ones) and set the attribute priority so department-level templates take precedence.
    * Use the [Automation Simulator](#testing-with-the-simulator-hris) to test your rules before a real onboarding.
  </Accordion>

  <Accordion title="What if no templates match during HRIS onboarding?">
    No applications are pre-selected, and the onboarding is announced in your HR Slack notification channel so someone can select templates or applications manually.
  </Accordion>

  <Accordion title="How do I handle contractors?">
    Create a contractor-specific template and use the "Employment Type" attribute: `Employment Type equals Contractor`.
  </Accordion>
</AccordionGroup>