=== Conditions in Conditional flows

As was mentioned in <<_execution-requirements, Execution requirements>>, _Condition_ executions can be only contained in _Conditional_ subflow.
If all _Condition_ executions evaluate as true, then the _Conditional_ sub-flow acts as _Required_.
You can process the next execution in the _Conditional_ sub-flow.
If some executions included in the _Conditional_ sub-flow evaluate as false, then the whole sub-flow is considered as _Disabled_.

==== Available Conditions

`Condition - User Role`::
This execution has the ability to determine if the user has a role defined by _User role_ field.
If the user has the required role, the execution is considered as true and other executions are evaluated.
The administrator has to define the following fields:

Alias:::
Describes a name of the execution, which will be shown in the authentication flow.

User role:::
Role the user should have to execute this flow.
To specify an application role the syntax is `appname.approle` (for example `myapp.myrole`).

`Condition - User Configured`::
This checks if the other executions in the flow are configured for the user.
The Execution requirements section includes an example of the OTP form.

`Condition - User Attribute`::
This checks if the user has set up the required attribute.
There is a possibility to negate output, which means the user should not have the attribute.
The <<_user-attributes,User Attributes>> section shows how to add a custom attribute.
You can provide these fields:

Alias:::
Describes a name of the execution, which will be shown in the authentication flow.

Attribute name:::
Name of the attribute to check.

Expected attribute value:::
Expected value in the attribute.

Negate output:::
You can negate the output.
In other words, the attribute should not be present.