Required Condition Configuration Guide

This guide explains how to configure and use Required Condition for Type Attributes and Relationship Type (Relation Type) Attributes.

What Required Condition Does

Required Condition lets an administrator make an attribute mandatory only in specific situations, using a Rule, instead of making it mandatory for every instance of a Type (or every relationship of a Relation Type).

An attribute is enforced as required when:

Attribute.Required == true   OR   RequiredCondition Rule evaluates true

If neither is true, the attribute stays optional. If the static Required checkbox is already checked, the attribute is always required and its Required Condition rule (if any) has no additional effect.

What Gets Configured

Required Condition can be configured on:

• Type Attributes — attributes attached to a Type, configured on the Type's Attributes tab.
• Relationship Type (Relation Type) Attributes — attributes attached to a Relation Type, configured on the Relation Type's Attributes tab.

Eligibility

The Rule dropdown for Required Condition is only available for an attribute when both are true:

• The attribute's static Required checkbox is unchecked. Once Required is checked, the attribute is unconditionally required and the Rule column shows - instead of the dropdown.
• The attribute's type is not Expression. Expression attributes are derived/calculated and are never eligible for Required Condition (client and server both skip them).

Any other attribute type (Text, Rich Text, Numeric, Currency, Date, DateTime, Picklist, Boolean, User, Reference, Attachment, and so on) is eligible.

Setup Steps in Admin App

1. Create the Rule

1. Login to Admin App.
2. Go to Schema > Rules.
3. Click Create Rule.
4. Enter a Rule Name that describes the condition (for example ProspectPartRequiredForPrototypeTasks).
5. Configure Attribute Filter Groups and Attribute Filter Conditions the same way you would for an Access Policy or Display Condition rule (see the Rules Configuration Guide).
6. Click Save.

Any Rule created under Schema > Rules can be selected as a Required Condition — there is no separate "Required Condition rule type" to pick.

2. Apply the Rule to a Type Attribute

1. Go to Admin App > Schema > Types.
2. Open the target Type.
3. Open the Attributes tab.
4. For the attribute you want to make conditionally required, make sure its Required checkbox is unchecked.
5. In the Rule column for that attribute, select the Rule you created.
6. Click Save.

3. Apply the Rule to a Relation Type Attribute

1. Go to Admin App > Schema > Relation Types.
2. Open the target Relation Type.
3. Open the Attributes tab.
4. For the attribute you want to make conditionally required, make sure its Required checkbox is unchecked.
5. In the Rule column for that attribute, select the Rule you created.
6. Click Save.

Quick Validation After Save

1. Create (or edit) an instance/relationship where the rule should evaluate false — confirm the attribute is optional.
2. Create (or edit) an instance/relationship where the rule should evaluate true, leave the attribute empty, and confirm Save is blocked with a validation message.
3. Fill in the attribute and confirm Save succeeds.

Configuration Model

A Required Condition rule is a normal Rule, built the same way as an Access Policy or Display Condition rule:

• Rule Groups combined with AND/OR operators.
• Conditions within each group, each with:
  • Attribute Context: Instance, User, or User Roles.
  • Attribute Name: The field to evaluate (hidden for User Roles context).
  • Condition Operator: For example Equals, In, Is Empty, Between.
  • First Value / Second Value: Static values, or dynamic User Profile attribute references (@User.<Attribute>).

Required Condition rules do not use a Rule's Error Message expression — the validation message shown when the attribute is missing is a fixed platform message (see Validation Behavior on Save), not the rule's own error message.

Rule Evaluation

Evaluation point	Enforced?	Notes
Client Side (SPA)	Yes	Re-evaluated reactively as any attribute value on the form changes, not only the field being edited, so Save disables itself as soon as a condition makes a currently-empty field required.
Server Side	Yes	Re-validated independently on Create Instance, Update Instance, Connect Relationship, and Update Connection — the client check is a UX convenience, not the source of truth.
Custom program (Program/Trigger logic)	No	Custom trigger programs do not evaluate Required Condition rules and are not needed to enforce them — enforcement happens in the platform's own Create/Update/Connect path. This replaces the need to hand-write that enforcement in a trigger program.

Validation Behavior on Save

Client Side

For a field with a Required Condition, the SPA computes its effective required state as field.isRequired || RequiredCondition rule result and treats it exactly like a statically required field for that instance:

• Shows the required-field asterisk when the condition is currently satisfied.
• Runs the same field validation used for static required fields.
• Disables Save while any conditionally-required field is both effectively required and empty.

Server Side

The server independently evaluates the same Rule against the values actually being saved/persisted (not the client's view of the form), and blocks the operation if a conditionally required attribute has no value:

• Attribute missing only because of Required Condition: Values for some conditionally required attributes ({0}) are missing.
• Attribute missing because of the static Required flag: Values for some required attributes ({0}) are missing.
• Both kinds missing on the same save: Values for some required attributes ({0}) and conditionally required attributes ({1}) are missing.

On relationship Connect/Update Connection, only the Required Condition rule is enforced — the static Required flag has never been enforced for relationship attributes, and that remains unchanged.

Where to Use Required Condition

Use Required Condition when an attribute should be mandatory only in specific business scenarios, not for every instance.

Example: Task/Prototype-Specific Required Fields

Goal: "Prospect Part" and "Required Delivery Date" should be mandatory only for specific Task/Prototype combinations, not for every Task.

Pattern:

• Context: Instance
• Attribute: Prototype / Task Type (or equivalent driving attribute)
• Condition: Equals / In the relevant value(s)
• Applied to: the Prospect Part and Required Delivery Date Type Attributes

Other Common Patterns

• Make a "Cancellation Reason" attribute required only when a Status attribute equals Cancelled.
• Make an "Approver" attribute required only when a numeric attribute (for example Amount) exceeds a threshold.
• Make a relationship attribute required only for relationships to a specific To-Type or where another relationship attribute has a specific value.

Schema Export and Import

• Type Attributes: The Required Condition rule is exported/imported by Rule name as part of the Type Attribute entry.
• Relation Type Attributes: Attributes with a Required Condition are exported/imported as a separate AttributeRequiredConditions list on the Relation Type schema, mapping attribute name to Rule name.
• On import, if the referenced Rule name does not exist in the target tenant, the import fails with an explicit error identifying the Type/Relation Type, attribute, and missing Rule name. Make sure any Rule referenced by a Required Condition is imported (or already exists) before importing the Type/Relation Type that references it.

Known Limitations

• A Required Condition rule cannot be configured while the attribute's static Required checkbox is checked — uncheck Required first if you need conditional enforcement instead.
• Expression attributes are never eligible for Required Condition.
• The same dynamic-value limitations that apply to Access Policy rules apply here: dynamic values resolve User Profile attributes, not Instance attributes, for the condition's first/second value.
• Required Condition does not carry its own denial/error message — the missing-attribute message is a fixed platform message, not the rule's configured Error Message expression.

Troubleshooting Checklist

If an attribute is unexpectedly optional or unexpectedly blocking Save:

1. Confirm the attribute's static Required checkbox state — a checked Required box always wins and makes the Rule column show -.
2. Confirm the attribute is not an Expression type.
3. Confirm the correct Rule is selected in the Rule column for that attribute on the Type/Relation Type.
4. Open the Rule under Schema > Rules and validate its conditions/groups independently.
5. Verify any dynamic values in the rule reference valid User Profile attributes.
6. Reproduce the save with the exact attribute values expected to trigger the condition, and check whether the failure message lists the attribute under the required or conditionally required group.
7. For relationship attributes, remember only the rule-based condition is enforced on Connect/Update Connection — the static Required flag is not.

Best Practices

• Keep Required Condition rules simple and business-focused, the same way you would for Access Policy or Display Condition rules.
• Give the Rule a descriptive name that states the business condition (for example ProspectPartRequiredForPrototypeTasks), since the same Rule list is shared across Access Policy, Display Conditions, and Required Condition.
• Prefer Required Condition over trigger-program logic for "this field must have a value when X" — it gives you client-side feedback for free and a single place to review the condition.
• Re-validate the rule after schema changes to the attributes it references.