> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-chore-teams-api-autoupdate.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Understand how rules apply to authorization policies and Auth0's role-based access system (RBAC).

# Rules for Authorization Policies

<Warning>
  The End of Life (EOL) date of Rules and Hooks will be **November 18, 2026**, and they are no longer available to new tenants created as of **October 16, 2023**. Existing tenants with active Hooks will retain Hooks product access through end of life.

  We highly recommend that you use Actions to extend Auth0. With Actions, you have access to rich type information, inline documentation, and public `npm` packages, and can connect external integrations that enhance your overall extensibility experience. To learn more about what Actions offer, read [Understand How Auth0 Actions Work](/docs/customize/actions/actions-overview).

  To help with your migration, we offer guides that will help you [migrate from Rules to Actions](/docs/customize/actions/migrate/migrate-from-rules-to-actions) and [migrate from Hooks to Actions](/docs/customize/actions/migrate/migrate-from-hooks-to-actions). We also have a dedicated [Move to Actions](https://auth0.com/extensibility/movetoactions) page that highlights feature comparisons, [an Actions demo](https://www.youtube.com/watch?v=UesFSY1klrI), and other resources to help you on your migration journey.

  To read more about the Rules and Hooks deprecation, read our blog post: [Preparing for Rules and Hooks End of Life](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
</Warning>

You can append [Rules](/docs/customize/rules) to the pre-configured authorization policy to exercise additional control over permitting or denying user access. A rule contains custom code that makes an authorization decision based on appropriate logic. When combined with other rules, it helps define what happens in different contexts.

Rules can restrict access based on any combination of attributes you store for users, such as user department, time of day, location, or any other user or API attribute (like username, security clearance, or API name).

For example, if you were using rules to provide finely-grained access control at a non-profit organization, you could give only W2 employees working in the Research and Development department in the New Delhi office access to an application.

For samples of rule implementations with authorization policies, read [Sample Use Cases: Rules with Authorization](/docs/manage-users/access-control/sample-use-cases-rules-with-authorization).

## Rules in the authorization process

Based on the order in which they run, rules can change the outcome of the authorization decision prior to the permissions being added to the <Tooltip tip="Access Token: Authorization credential, in the form of an opaque string or JWT, used to access an API." cta="View Glossary" href="/docs/glossary?term=Access+Token">Access Token</Tooltip>. The basic process with rules injected is as follows:

1. The user tries to authenticate with the application.
2. Auth0 brings the request to the selected identity provider.
3. Once the identity provider confirms that user credentials are valid, all created rules run in the order in which they are configured in the Dashboard.
4. Assuming no rule has restricted the user's access, the user is authorized to access the application.

## Learn more

* [Role-Based Access Control](/docs/manage-users/access-control/rbac)
* [Configure Core Authorization Features for Role-Based Access Control](/docs/manage-users/access-control/configure-core-rbac)