---
title: "Optional rules - Data Center"
canonical: "https://support.appfire.com/space/CSOT/68752312/Optional%20rules%20-%20Data%20Center"
format: markdown
---
> Macro (aura-html)

# <span style="color: #333333">Description</span>

<span style="color: #333333">Create Issue and Create Sub-task post functions can be configured to create the issue only if certain conditions have been met by the issue which is in transition.</span>

## <span style="color: #333333">Conditions</span>

<span style="color: #000000">Define the conditions under which to create the new issue(s) or sub-task(s). If these conditions are not met, then no issues or sub-tasks are created. If you do not define any conditions, then your issues and sub-tasks are always created when the associated workflow transition occurs. </span>There are two types of conditioning, they are:

- **Sub-task conditioning** - prevents the creation of sub-tasks if the original issue is a sub-task and the configuration indicates not to create a sub-task. It has the optional capability to create a sub-task which is a sibling of the original issue.
- **Pattern matching conditioning** - takes advantage of the find/replace capabilities to provide a very flexible way to condition issue creation based on matching issue information with a [regex pattern](http://www.regular-expressions.info/reference.html). Although this is a more complex configuration, it is highly powerful in that it covers a great number of use cases. [Pattern matching conditioning](https://appfire.atlassian.net/wiki/x/MBYZB) includes additional details.

| Field | Create Issue  
(Available) | Create Sub-task  
(Available) | Default | Description |
| --- | --- | --- | --- | --- |
| Create if original issue is a sub-task | :cross_mark: | :check_mark: |  | Only create the issue if the original issue is a sub-task. |
| Sub-task default handling | :cross_mark: | :check_mark: |  | Recommend to **not** select this option unless needed. Select to have Jira default sub-task create handling applied. Selecting this may override settings provided in the create configuration like setting fix versions. Defaulting behavior is similar to how sub-tasks are created from the UI.<br>Example scenarios where you may need this:<br>- You need a create listener to access the issue parent
- You have a post function on the create issue transition that needs access to the parent |
| Condition 1 | :check_mark: | :check_mark: |  | Using [substitution variables](https://appfire.atlassian.net/wiki/spaces/CSOT/pages/68752493), you can specify a value or exact match. |
| Condition 2 | :check_mark: | :check_mark: |  | Using [substitution variables](https://appfire.atlassian.net/wiki/spaces/CSOT/pages/68752493), you can specify a value or exact match. If both Condition 1 and Condition 2 are specified then both conditions must match in order for the issues to be created. The conditions are ANDed together. |
| Regular expression pattern | :check_mark: | :check_mark: |  | Specify a regex pattern for conditional matching. The pattern is applied to the Condition field to the left (e.g., Condition 1, or Condition 2). |
| Exact, Literal, Negative | :check_mark: | :check_mark: |  | Specify how the regex pattern should be evaluated.<br>- **Exact** - The pattern must be an exact match.
- **Literal** - Treat any special characters in the pattern as literal characters.
- **Negative** - Reverse the condition so that the condition is true if the match is false and vice versa. |

## <span style="color: #333333">Configuration</span>

<span style="color: #000000">Define additional configurations for the issues or sub-tasks being created.</span>

| Field | Create Issue  
(Available) | Create Sub-task  
(Available) | Default | Description |
| --- | --- | --- | --- | --- |
| Acting user | :check_mark: | :check_mark: | The user logged in who is transitioning the workflow | Set a user who would have the same permissions as the *Assignee *for issue being created. This provides the flexibility to the specified user to perform the workflow transition.<br>> ℹ️ When you select *None *for this field, *Acting user *is defaulted to the user transitioning the workflow. |
| JQL query | :check_mark: | :check_mark: |  | Define a JQL query that can be used to populate substitution substitution variables that can be used within individual fields or conditions and regular expressions. The substitution variables include:<br>- %jql_result_count%
- %jql_result_list%
- %jql_result_1% |
| Create multiple issues | :check_mark: | :check_mark: |  | Using [substitution variables](https://appfire.atlassian.net/wiki/spaces/CSOT/pages/68752493), you can specify a value or exact match to create multiple issues. See: How to create multiple issues. |
| Regular expression pattern | :check_mark: | :check_mark: |  | Specify a regex pattern for conditional matching. The pattern is applied to the Condition field to the left (e.g., Condition 1, or Condition 2). |
| Exact, Literal Negative | :check_mark: | :check_mark: |  | Specify how the regex pattern should be evaluated.<br>- **Exact** - The pattern must be an exact match.
- **Literal** - Treat any special characters in the pattern as literal characters.
- **Negative** - Reverse the condition so that the condition is true if the match is false and vice versa. |