# Advanced Activity Rules

{% hint style="success" %}
**Audience:** Admins and Technical Builders, Implementors, and Developers

**Purpose:** Explains how Advanced <code class="expression">space.vars.activity</code> Rules work in <code class="expression">space.vars.Kizen\_company\_name</code> and how they affect <code class="expression">space.vars.activity</code> field visibility and validation across the platform.
{% endhint %}

## Overview

Advanced <code class="expression">space.vars.activity</code> Rules allow you to apply conditional logic that controls when <code class="expression">space.vars.activity</code> fields are shown and how validation behaves during submission. These rules are enforced both in the UI and on the backend, ensuring consistent behavior across UI manual entry and <code class="expression">space.vars.automations</code>.

### When to Use Advanced Activity Rules

Use Advanced <code class="expression">space.vars.activity</code> Rules when you need to:

* Show <code class="expression">space.vars.activity</code> fields only when relevant
* Apply conditional validation without creating multiple <code class="expression">space.vars.activity</code> Types
* Support multiple workflows within a single <code class="expression">space.vars.activity</code> Type
* Reduce form complexity while maintaining structured data capture

***

## Rule Components

Advanced <code class="expression">space.vars.activity</code> Rules are composed of the following elements.

| Rule Component                   | Description                                                                                                                                                                                                                                     |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Trigger or Condition Fields**  | The field whose value determines when a rule applies. All Field types can be used as conditions.                                                                                                                                                |
| **Operators and Conditions**     | Each condition includes a comparison operator (for example, *equals* or *does not equal*) and a comparison value. Available operators depend on the selected field type.                                                                        |
| **Condition Logic**              | Defines how multiple conditions are evaluated. **ANY** applies the rule if any condition is met (logical OR). **ALL** applies the rule only if all conditions are met (logical AND). This setting applies to all conditions within the rule.    |
| **Target Fields (Shown Fields)** | Defines which <code class="expression">space.vars.activity</code> fields are shown when rule conditions are met. Any Activity field can be selected as a target. Fields not selected remain hidden. A field can only be controlled by one rule. |

### How Rules Are Evaluated

Advanced <code class="expression">space.vars.activity</code> Rules are evaluated:

* When the <code class="expression">space.vars.activity</code> form loads
* When a trigger field value changes
* When the <code class="expression">space.vars.activity</code> is submitted
* During backend validation (UI & <code class="expression">space.vars.automations</code>)

Each field can appear only once in the **Show the following field(s)** selector, so a field's visibility is controlled by a single rule. This prevents conflicts where one rule would show a field, and another would hide it, and means rule order does not affect which fields are displayed.

{% hint style="info" %}
**Note:** Required fields are not required if they are hidden from the user.
{% endhint %}

### Rule Effects, Behavior, and Limitations

Advanced <code class="expression">space.vars.activity</code> Rules affect <code class="expression">space.vars.activity</code> behavior in the following ways:

* Hidden required fields are ignored during validation
* Validation behavior is consistent across UI and backend submissions
* Rules do not modify stored values or historical <code class="expression">space.vars.activity</code> records

They have the following limitations:

* A field can only be controlled by one rule
* A field can be used as a trigger for multiple rules
* Rules control visibility and validation only
* Rules do not assign values, update records, or alter historical data

***

## Permissions and Advanced Rules

Advanced Rules control when fields are shown, not whether users can edit them.

* Rules are evaluated regardless of permissions, meaning the logic still runs even if the user cannot access certain fields.
* If a rule condition references a field the user cannot access, that field is treated as **blank** during evaluation.
* Permissions still control editability. If a field is read-only due to permissions, the user can see it (if shown by the rule) but cannot edit it.

{% hint style="warning" %}
**Caution:** If a required field becomes read-only due to permissions, the form cannot be submitted. This is a configuration issue and should be resolved by adjusting permissions or rule logic.
{% endhint %}

***

## Industry Examples

{% tabs %}
{% tab title="Insurance" %}
**Conditional Claim Follow-Up**\
Show additional fields such as Claim Denial Reason or Adjuster Notes only when a claim outcome is marked as Denied. This ensures required details are captured without cluttering the <code class="expression">space.vars.activity</code> form for approved claims.

**Escalation Tracking**\
Display Supervisor Review Required and Escalation Reason fields only when a claim exceeds a defined severity or dollar threshold.

**Policyholder Communication Paths**\
Show different <code class="expression">space.vars.activity</code> fields based on the communication method selected (Email, Phone, or In-Person), allowing agents to log channel-specific details accurately.
{% endtab %}

{% tab title="Healthcare" %}
**Appointment Outcome Documentation**\
Show No-Show Reason or Reschedule Date fields only when an appointment <code class="expression">space.vars.activity</code> is marked as Missed or Rescheduled, reducing unnecessary data entry for completed visits.

**Care Pathway Differentiation**\
Display different follow-up fields depending on whether an <code class="expression">space.vars.activity</code> relates to **Initial** Consultation, Treatment, or Post-Care Follow-Up.

**Compliance and Consent Capture**\
Require consent-related fields only when certain care types or procedures are selected, ensuring compliance without over-collecting information.
{% endtab %}

{% tab title="Financial Services" %}
**Transaction Review and Exception Handling**\
Show Exception Reason or Compliance Notes fields only when a transaction <code class="expression">space.vars.activity</code> is flagged for review, supporting audit requirements without slowing routine processing.

**Client Interaction Classification**\
Display different <code class="expression">space.vars.activity</code> fields based on interaction type, such as Advisory Call, Account Maintenance, or Issue Resolution, enabling consistent client records.

**Follow-Up Requirements**\
Require follow-up scheduling details only when an <code class="expression">space.vars.activity</code> outcome indicates further action is needed, such as additional documentation or client approval.
{% endtab %}
{% endtabs %}

***

## What’s Next

Next, continue to [Adding Advanced Activity Rules](/docs/concepts/activities/advanced-activity-rules/adding-advanced-activity-rules.md), which explains how to configure rules using the <code class="expression">space.vars.Kizen\_company\_name</code> UI so you can understand:

* How to define rule conditions and logic
* How to select fields to show when conditions are met
* How rule order and required fields affect <code class="expression">space.vars.activity</code> submission

Reviewing the UI configuration steps prepares you to design and test <code class="expression">space.vars.activity</code> Rules confidently before using them in production.

<details>

<summary>Related Topics</summary>

* [Activities](/docs/concepts/activities.md)
* [Activities Core Concepts](/docs/concepts/activities/activities-core-concepts.md)
* [Activities Data Model](/docs/concepts/activities/activities-data-model.md)
* [Activity Permissions](/docs/concepts/activities/activity-permissions.md)
* [Activities API & Webhooks](/docs/concepts/activities/activities-api-and-webhooks.md)

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.kizen.com/docs/concepts/activities/advanced-activity-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.