ABAC Conditions

Conditions are the building blocks of rules. They define the criteria that determine when a rule should apply. A condition can be used in multiple rules.

Note: When using a condition in a rule, you can invert its logic using the "Not" option. See the Rules section for details.

Creating Conditions

Click the Manage Conditions tab
Click + New condition

The Add Condition dialog appears with the following fields:

Condition Name (required) - A descriptive name for your condition. Make it clear so you can easily find and reuse it later.
Example: "Is Nurse Caregiver"

Description (optional) - Explain what criteria this condition evaluates. Including a clear description will help you and your team understand it later.
Example: "Checks if the initiator is a caregiver with template name 'nurse'"

Condition Type (required) - Select the condition type to use. Currently, the only type available is InitiatorAttributeInParamsCondition, which checks if a user's attribute matches specific values.

After selecting the condition type, additional fields appear:

Initiator Attribute Name (required) - The attribute of the user making the API call that you want to check. The "initiator" is the user invoking the API.

To see all available attributes, refer to the Get Self API response - any field returned can be used here. The most common attribute to check is _template.name (e.g., "nurse", "doctor", "patient").

For a deeper understanding of initiator data and what information is available when conditions are evaluated, see the Understanding Context section below.

Values (required) - The specific values to match against. If the user's attribute matches any value in this list, the condition is true. Click + Add Value to add each value.

Example: "nurse" (the condition will be true if the user's template name is "nurse")

Finding template names: The most common use case is checking _template.name to identify specific user types. Template names are not fixed values. To find a template's exact JSON name, go to Console → Templates → click the template → Overview tab → the Json name field shows the value to use.

Managing Existing Conditions

The Manage Conditions tab shows all available conditions in your environment. Each condition displays:

Condition Name - The condition's identifier
Description - What criteria does the condition evaluate?
Type - The condition type (e.g., InitiatorAttributeInParamsCondition, CompositeCondition)
Tags:
- Built-in: System condition, cannot be deleted
- Built-in - Modified: System condition that has been edited
- Custom: User-created condition

❗️
Important:

Conditions are reusable. A single condition can be used in multiple rules.

Before deleting a custom condition, verify it's not in use by any rules. Removing a condition from an active rule means it runs without that check. Rules with no conditions will execute their actions on every API call.

If you edit a condition that's used in multiple rules, the change will affect all those rules.

Understanding Context

When you create conditions, you need to know what information is available to check. This information is called "context."

Why does this matter?

Conditions work by evaluating data about users or entities in the system. To write effective conditions, you need to understand what data is available and where it comes from.

What data is available?

Initiator data - Information about the user making the API call. This is what you'll use most when creating conditions.

The most common example is checking the user's template name to determine what type of user is making the request (e.g., is this user a nurse or a doctor?).

All initiator attributes come from the Get Self API. This API returns information about the logged-in user, and any field in that response can be used in your conditions.

Entity data - Information about the entity being accessed (like a specific patient, device, or organization). Entity data may not always be available. For example, when searching entities, there is no single entity whose data can be used for evaluation. When available, entity data comes from the relevant "Get By ID" API for that entity type (e.g., Get Caregiver By ID for caregiver entities).

Note: Entity-based conditions are not currently supported in the UI, so you'll work primarily with initiator data.