# Post-job scripts
{% hint style="info" %}
**Required license:** Professional or Enterprise
{% endhint %}
When a database generation job is complete, Tonic Structural can execute custom SQL scripts on the destination database.
Post-job scripts allow you to make adjustments to the destination database. For example, you might have a set of regular demo users that you always want to have available. You can use a post-job script to add these demo users to the destination database after each data generation run.
## Displaying the list of post-job scripts
You manage post-job scripts from the **Post-Job Actions** view. To display the **Post-Job Actions** view, either:
* On the workspace management view, in the workspace navigation bar, click **Post-Job Actions**.
* On **Workspaces** view, from the dropdown menu in the **Name** column, select **Post-Job Actions**.
On the **Post-Job Actions** view, the **Scripts** list contains the list of post-job scripts.
For each post-job script, the list contains:
* A toggle to enable or disable the script.
* The name of the script.
* The user who created the script.
* The date and time when the script was most recently updated.
* Options to edit or delete the script.
## Creating and configuring post-job scripts
{% hint style="info" %}
**Required workspace permission:** Configure post-job scripts and webhooks
{% endhint %}
### Creating a script
To create a post-job script, in the **Post-Job Scripts** panel, click **Create Post-Job Script**.
On the script configuration dialog, provide the script details, then click **Save**.
### Configuring a script
On the script configuration dialog:
1. In the **Script Name** field, provide a name for the script.
2. In the **SQL Script** field, type or paste the SQL script.\
\
For a MySQL database, you must explicitly pass a `USE` statement to define the database.
3. To format the script for readability, click **Beautify**.
4. By default, if a post-job script fails, then Structural registers a warning, but the data generation job does not fail.\
\
To instead fail the data generation job, toggle **Enable Warnings** to the off position.
5. To save the script configuration, click **Save**.
### Editing a script
To edit a post-job script:
1. In the **Scripts** list, click the edit icon for the script.
2. On the script configuration dialog, make the updates to the script.
3. Click **Save**.
## Deleting a script
{% hint style="info" %}
**Required workspace permission:** Configure post-job scripts and webhooks
{% endhint %}
To delete a post-job script configuration:
1. In the **Scripts** list, click the delete icon for the script.
2. On the confirmation dialog, click **Delete**.
## Managing script execution
{% hint style="info" %}
**Required workspace permission:** Configure post-job scripts and webhooks
{% endhint %}
### Changing the script execution sequence
In the **Scripts** list, the script display sequence determines the execution sequence. The script at the top of the list is executed first, and the others follow in order from top to bottom.
To change the execution sequence, change the display sequence.
To execute a script earlier, drag it to a higher location in the list.
To execute a script later, drag it to a lower location in the list.
### Enabling and disabling scripts
You use the toggle at the left of each script to control whether the script is enabled.
When the toggle is in the on position, the script runs.
When the toggle is in the off position, the script does not run.
## Viewing and managing configuration inheritance
{% hint style="info" %}
**Required license:** Enterprise license.
{% endhint %}
### Managing the inheritance status for a child workspace
By default, a child workspace inherits the configured post-job scripts from its parent workspace.
If you make any changes to the child workspace configuration, including adding, editing, or deleting a script, the inheritance is removed. The child workspace no longer inherits any post-job script changes from its parent workspace.
For a child workspace, the **Post-Job Scripts** view indicates the current inheritance status.
Child workspace inherits the parent configuration
* **Inherits parent configuration** means that the child workspace inherits the post-job scripts from the parent workspace.
* **Overrides** parent configuration means that the child workspace does not inherit the post-job scripts from the parent workspace.
To reset the inheritance, in the **Overrides parent configuration** notice, click **Reset**, then on the confirmation dialog, click **Reset** again.
Option to reset inheritance on a child workspace
The overrides are removed. The child workspace inherits any subsequent configuration changes from the parent workspace.
### Viewing the inheritance status for children of a parent workspace
For a parent workspace, you can view the current inheritance status of the child workspaces.
The **Child Workspaces** tab contains the list of child workspaces.
Child Workspaces tab for a parent workspace
For each workspace, the list includes:
* The workspace name.
* The inheritance status.\
\
**Inheriting** indicates that the child workspace inherits the configuration from the parent.\
\
**Overriding** indicates that the child workspace overrides the configuration and does not inherit it from the parent.
* Your role in the child workspace.
* The owner of the child workspace.
You cannot reset the inheritance status from the **Child Workspaces** tab. If you have access to a child workspace, then to switch to that workspace, click the arrow icon in the rightmost column.
