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

> Learn about custom database action script templates.

# Custom Database Action Script Templates

<Card title="Availability varies by Auth0 plan">
  Your Auth0 plan or custom agreement affects whether this feature is available. To learn more, read [Pricing](https://auth0.com/pricing).
</Card>

If you have your own database (known as a legacy data store in Auth0) containing user identity data, you can use it as an <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=identity+provider">identity provider</Tooltip> to authenticate users.
You create and configure the connection to your legacy data store as a custom database in Auth0. You can choose to migrate data to Auth0's data store from your legacy database incrementally over time, or you can continue to use it without migrating data. We provide script templates to perform functions on the custom database that you can use and customize.

There are two different types of custom database scripts:

* **Automatic Migration**: Whenever a user logs into Auth0, if the user is not yet in Auth0, the script will check the legacy database to see if the user exists there. If found and the **Import users to Auth0** flag is turned on, the user data migrates the user to Auth0 data store. This capability is sometimes called **trickle migration** or **lazy migration**.
* **Legacy Database**: Auth0 will always query the underlying database when a user tries to log in, is created, changes their password, verifies their email, or is deleted. If found and the **Import users to Auth0** flag is **not** turned on, user data stays in the legacy database and does **not** migrate to Auth0.

Auth0 provides the following custom database action scripts:

* [Change Password](/docs/authenticate/database-connections/custom-db/templates/change-password)
* [Create User](/docs/authenticate/database-connections/custom-db/templates/create)
* [Delete User](/docs/authenticate/database-connections/custom-db/templates/delete)
* [Get User](/docs/authenticate/database-connections/custom-db/templates/get-user)
* [Login](/docs/authenticate/database-connections/custom-db/templates/login)
* [Verify User](/docs/authenticate/database-connections/custom-db/templates/verify)
* [Change Email](/docs/authenticate/database-connections/custom-db/templates/change-email)

<Card title="Network firewall">
  If you are behind a firewall, this feature may require that you add the appropriate Auth0 IP addresses to the Allow List to work properly.
</Card>

## Script execution

As described in [Custom Database Connections](/docs/authenticate/database-connections/custom-db), a custom database connection type allows you to configure action scripts: custom code that is used when interfacing with your legacy identity store. Each action script is essentially a named JavaScript function that is passed a number of parameters, with the name of the function and the parameters passed depending on the script.

### Limits

Action script execution supports the asynchronous nature of JavaScript, and constructs such as [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) objects can be used. Asynchronous processing effectively results in suspension pending completion of an operation, and an Auth0 serverless Webtask container typically has a 20-second execution limit, after which the container may be recycled. Recycling a container due to this limit will prematurely terminate operation, ultimately resulting in an error condition being returned (as well as resulting in a potential reset of the `global` object).

### Completion and the callback function

The `callback` function supplied to each action script effectively acts as a signal to indicate completion of operation. An action script should complete immediately following a call to the `callback` function (either implicitly or by explicitly executing a JavaScript return statement) and should refrain from any other operation.

<Warning>
  The Auth0 supplied `callback` function must be called exactly **once**; calling the function more than once within an action script will lead to unpredictable results and/or errors.
</Warning>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Where `callback` is executed with no parameters, as in `callback()`, the implication is that function has been called as though `callback(null)` had been executed.
</Callout>

If an action script uses asynchronous processing, then a call to the `callback` function must be deferred to the point where asynchronous processing completes, and must be the final thing called. Asynchronous execution will result in a JavaScript `callback` being executed after the asynchronous operation is complete; this callback is typically fired at some point after the main (synchronous) body of a JavaScript function completes.

<Warning>
  Failure to execute the `callback` function will result in a stall of execution, and ultimately in an error condition being returned. The action script must call the `callback` function exactly once: the `callback` function must be called at least once in order to prevent stall of execution, however it must not be called more than once otherwise unpredictable results and/or errors will occur.
</Warning>