<commit_before>---
description: Best practices for writing and managing Auth0 Rules.
toc: true
topics:
  - best-practices
  - rules
contentType: reference
useCase:
  - best-practices
  - rules
---

# Rules Best Practices

This article covers some best practices when using [rules](/rules). Rules can be used in a [variety of situations](/rules#what-can-i-use-rules-for-) as part of the authentication pipeline where protocol specific artifacts are generated &mdash;i.e., an ID Token in [OpenID Connect (OIDC)](/protocols/oidc), an <dfn data-key="access-token">Access Token</dfn> in [OAuth 2.0](/protocols/oauth2), or an [assertion in SAML](/protocols/saml/saml-configuration/saml-assertions#use-rules). A new pipeline, in which rules execute, is created for each authentication request.

A number of [pre-existing Rules/Rule templates](https://github.com/auth0/rules) are provided out-of-box to help you achieve your goal(s). However, there are times when you will want to [build your own Rule(s)](/rules/guides/create) in support of your specific functionality/requirements. You may choose to extend or modify a pre-existing Rule/Rule template, or you may choose to start from scratch (using one of our [samples](/rules/references/samples) to guide you). Either way, there are a number of best practices that you’ll want to adopt to ensure that you achieve the best possible outcome.

![Rules Dashboard](/media/articles/rules/rules-best-practice-dashboard.png)

The image above depicts an [Auth0 Dashboard](/dashboard) showing a number of enabled and disabled rules for a specific [Auth0 Tenant](/getting-started/the-basics#account-and-tenants). Enabled rules&mdash;those with the green toggle&mdash;are those rules that are active and will execute as part of a pipeline. Disabled rules&mdash;those with the greyed-out toggle&mdash;on the other hand, won't. 

## Anatomy

A rule is essentially an anonymous JavaScript function that is passed 3 parameters: a [`user`](#user-object) object, a [`context`](#context-object) object, and a [`callback`](#callback-function) function. 

```js
    function (user, context, callback) {
        // TODO: implement your rule
        return callback(null, user, context);
    }
 ```

::: note
**Do not** be tempted to add a trailing semicolon at the end of the function declaration as this will break rule execution. Also, anonymous functions make it hard in [debugging](#debugging) situations to interpret the call-stack generated as a result of any [exceptional error](#exceptions) condition. For convenience, consider providing a function name using some compact and unique naming convention to assist with diagnostic analysis (e.g., `function MyRule1 (user, context, callback) {...}`). 
:::
<commit_msg>Removed extraneous space around mdash<commit_after>---
description: Best practices for writing and managing Auth0 Rules.
toc: true
topics:
  - best-practices
  - rules
contentType: reference
useCase:
  - best-practices
  - rules
---

# Rules Best Practices

This article covers some best practices when using [rules](/rules). Rules can be used in a [variety of situations](/rules#what-can-i-use-rules-for-) as part of the authentication pipeline where protocol specific artifacts are generated&mdash;i.e., an ID Token in [OpenID Connect (OIDC)](/protocols/oidc), an <dfn data-key="access-token">Access Token</dfn> in [OAuth 2.0](/protocols/oauth2), or an [assertion in SAML](/protocols/saml/saml-configuration/saml-assertions#use-rules). A new pipeline, in which rules execute, is created for each authentication request.

A number of [pre-existing Rules/Rule templates](https://github.com/auth0/rules) are provided out-of-box to help you achieve your goal(s). However, there are times when you will want to [build your own Rule(s)](/rules/guides/create) in support of your specific functionality/requirements. You may choose to extend or modify a pre-existing Rule/Rule template, or you may choose to start from scratch (using one of our [samples](/rules/references/samples) to guide you). Either way, there are a number of best practices that you’ll want to adopt to ensure that you achieve the best possible outcome.

![Rules Dashboard](/media/articles/rules/rules-best-practice-dashboard.png)

The image above depicts an [Auth0 Dashboard](/dashboard) showing a number of enabled and disabled rules for a specific [Auth0 Tenant](/getting-started/the-basics#account-and-tenants). Enabled rules&mdash;those with the green toggle&mdash;are those rules that are active and will execute as part of a pipeline. Disabled rules&mdash;those with the greyed-out toggle&mdash;on the other hand, won't. 

## Anatomy

A rule is essentially an anonymous JavaScript function that is passed 3 parameters: a [`user`](#user-object) object, a [`context`](#context-object) object, and a [`callback`](#callback-function) function. 

```js
    function (user, context, callback) {
        // TODO: implement your rule
        return callback(null, user, context);
    }
 ```

::: note
**Do not** be tempted to add a trailing semicolon at the end of the function declaration as this will break rule execution. Also, anonymous functions make it hard in [debugging](#debugging) situations to interpret the call-stack generated as a result of any [exceptional error](#exceptions) condition. For convenience, consider providing a function name using some compact and unique naming convention to assist with diagnostic analysis (e.g., `function MyRule1 (user, context, callback) {...}`). 
:::

{'fraction_non_alphanumeric': 0.09722474152004354, 'fraction_numerical': 0.0032650099764193726, 'mean_word_length': 4.672839506172839, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1341921', 'n_tokens_mistral': 1512, 'n_tokens_neox': 1467, 'n_words': 659}