Eligibility Rule
What It Is
An eligibility rule gives staff a common expression of who qualifies. A membership director can use the same definition of an active member wherever an application needs that answer. Sharing the expression makes its meaning reviewable in one place instead of leaving separate copies to drift. The administrator creates a named rule about contacts or organizations and builds its expression from the conditions available in the workspace.
The rule has a readable identity that persists through changes to its name or expression. Descriptive information helps other staff recognize its purpose, and a sentence beneath the builder explains the expression. The enduring rule and its individual releases are distinct: staff can revise a draft without changing the expression already in use. Version history keeps the earlier expressions available for inspection and restoration.
What It Is Not
A rule does not grant a security role or permission. It supplies a qualification answer that another application interprets. A saved query retrieves a collection of records, whereas ordinary rule evaluation answers a question about supplied subjects. The use of a rule also remains a separate record: each consumer needs its own version choice and treatment of uncertainty.
How It Is Used
Administrators move between authoring, trial evaluation, release history and dependency review. A few representative subjects help them spot unexpected results before publication. Usage provides context for the people maintaining dependent prices, roles and processes. A replacement can be introduced while existing uses move gradually. Draft work is easy to mistake for a live change, and colleagues can replace one another’s draft when they omit the version check.
Its Facets
Identity and description. A permanent readable key accompanies the name, description, tags and subject kind. Recognizing a shared qualification definition as its wording changes.
Expression structure. Conditions, all/any/none groups and related-record blocks express the qualification question. Combining available facts into an inspectable decision.
Application vocabulary. Registered conditions describe their operators, choices and explanation, filtered by licensed applications. Keeping the builder aligned with evaluable application information.
Inputs. Parameters vary by use, while consumer-supplied facts describe the current question. Adapting one expression to different thresholds and situations.
References. Included published expressions can follow release changes or remain pinned. Composing qualification definitions without copying their conditions.
Draft and releases. An editable draft sits beside numbered historical expressions, effective periods and change notes. Reviewing, scheduling and restoring changes.
Ownership and reuse. A rule can be product-private, workspace-shared or Platform-provided and has a recorded owner. Distinguishing specialized expressions from the shared library.
Standing. Active, deprecated and archived describe whether the rule welcomes new work or is being retired. Moving dependencies away from obsolete definitions safely.
Readable wording. A staff summary explains the expression, while portal wording explains an uncertain closed-policy result. Helping authors and members understand the relevant answer.
Accountable changes. Writes create a trail with actors and relevant version or simulation information. Explaining who changed the definition and when.
How It Relates
Rule uses connect the expression to application decisions, and recorded decisions preserve the version that answered. CRM and other applications own the source records and declare the conditions that read them. Platform owns the shared rule record and coordinates its releases. Security, Commerce and Websites remain responsible for the actions they take from eligibility answers.
What It Could Become
The product should consider shared regression examples when several authors maintain the same rules. Saved cases currently remain in a browser. Optional publishing approval and individual-version withdrawal also remain delivery questions. Calculated expressions and further application declarations could broaden the vocabulary, while keeping a clear distinction between a recorded implementation and Product approval.