Onboarding Rules - Article

What an Onboarding Rule is

An Onboarding Rule connects information about a user with an automatic action.

For example:

• Enroll every newly provisioned service technician in the current safety program.
• Assign a country-specific compliance activity only to employees hired after a defined date.
• Add distributors from selected organizations to a product Community.
• Ask users in one role to complete a profile-enrichment Questionnaire after login.
• Present a mandatory policy document to a defined audience.
• Show an incentive-program explainer video again at a chosen interval.

Each rule has three conceptual parts:

The rule does not continuously scan every user. A published rule is evaluated when one of its supported triggers occurs. Hire-date rules can also use daily processing, and Apply rule immediately can deliberately evaluate existing users when the rule is published or updated.

The essential behavior

Onboarding Rules add outcomes. They do not later reverse those outcomes. If a user is enrolled while matching a rule and then changes job function, Eurekos does not automatically cancel the enrollment. If the user earned a certificate, a later profile change does not revoke it.

Where Onboarding Rules are configured

Open Settings → Onboarding to manage the rules.

Onboarding is documented with Course Administration because Training Activity assignment is one of its most important uses. Its current configuration entry point remains in Settings because the same rule can also assign Communities and present platform-level content at login.

Access depends on the user's administrative role, permissions, organization scope, and platform configuration. Platform and Global Administrators normally control Settings.

When to use Onboarding Rules

Use a rule when all three of these statements are true:

1. The audience can be identified reliably from structured profile information.
2. The same action should happen whenever a user enters that audience.
3. The action should occur without an administrator or participant making an individual selection.

Good uses include:

• Role-based induction
• Country, state, language, or organization-specific compliance
• Product training for partner or distributor segments
• Training assigned relative to hire date
• Community membership based on a stable business attribute
• Profile enrichment or acknowledgement at login
• Mandatory platform guidance for a defined population

Use another enrollment route when it better matches the process

Onboarding can coexist with these routes. A user may be created by SSO, updated by an import, automatically assigned one activity, and later self-enroll in another. Define which process owns each outcome so administrators can explain how every participant arrived.

For more detail, see Enroll and register participants.

Understand what triggers evaluation

An Onboarding Rule runs only when it is published and a supported trigger occurs. The available trigger paths serve different purposes.

The profile values stored at evaluation time determine whether the user matches. The route that created or updated those values can be signup, administration, import, API, SSO, or another integration.

First login

At first login, Eurekos evaluates published rules against the user's available onboarding profile values. This includes an SSO-created or SSO-updated account when the identity provider has supplied the required values.

Test the normal user login rather than masquerading as the user. A preview or administrator masquerade does not reproduce the complete trigger behavior.

Apply upon user creation

Enable Apply upon user creation when a rule should run immediately after a matching account is created. User login and later profile updates are not required for this trigger.

Use it only when all required audience values are reliably available at account creation. If an integration creates the account first and supplies important attributes later, the creation-time evaluation can occur before the profile is ready; the later supported update can then provide another evaluation opportunity.

Profile updates

By default, a profile update can trigger onboarding when one of the supported onboarding-related fields is updated. The current supported set includes the standard options and vocabularies that might have been named differently by an Administrator of the platform:

• Job function
• Department
• Workplace
• Category
• Unit
• Location code
• Type
• Role
• Language
• Organization
• Active
• Employment type
• User type
• Country
• State

This includes updates made through user import. Blocking a user changes the active profile state and is treated as a profile update.

The changed field does not have to be a criterion in one particular rule. When a supported profile update triggers evaluation, published rules whose audiences match the user's resulting profile can run. This is the current behavior; the older design in which only a changed criterion field triggered its corresponding rule is outdated.

Some platforms can be configured to evaluate rules after any profile update or even a re-save. If results suggest this broader behavior, confirm the platform-specific onboarding configuration with the Platform Administrator or Eurekos support.

Do not assume that an activity edit, certificate change, progress update, or another non-profile action re-runs onboarding.

Apply a published rule to existing users

A draft rule does not run. Publishing activates the rule for its normal triggers. When a new or updated rule is published, Apply rule immediately can be offered so the administrator can evaluate all existing users and assign the configured outcome to those who currently match.

Choose deliberately:

• Select Proceed when the validated rule should be applied to the existing matching population now.
• Decline when the rule should apply only as its standard triggers occur, such as first login or a later supported profile update.

Immediate application is an operational action, not a preview. It can affect a large population and can apply onboarding content again. Content-specific duplicate checks still determine the exact result—for example, Training Activity assignment skips a user who already has a signup in that activity.

Before proceeding, confirm the expected audience count, selected content, notification behavior, activity capacity, financial effects, and overlap with other published rules.

Hire-date evaluation

Hire date can target:

• Users hired before a specified date
• Users hired after a specified date
• Users a specified number of days after hire

Before/after-date criteria can be evaluated when the Hire date is supplied or updated and through the other applicable user triggers. Rules based on a specific number of days after hire use daily processing so the milestone can be reached without another manual profile change.

Test the stored date, boundary day, platform time zone, and what should happen when a Hire date is added or corrected after the intended milestone.

Build a reliable audience from profile data

An Onboarding Rule is only as reliable as the data it evaluates. Typical audience criteria include:

• Country
• State/Region
• Language
• Organization
• Suborganization
• Job function
• Department
• Workplace or Product-related workplace tags
• Category
• Unit
• Location code
• Type
• System Role
• Active status
• Employment type
• User type
• Hire date
• Other enabled, onboarding-capable user-profile attributes available on the platform

The exact fields available reflect the platform's User Profile and Forms configuration. Fields such as Active, Employment type, and User type are available to the rule builder only when enabled on an applicable Profile, Create user, or Signup form. A field that is disabled, hidden from every relevant process, or never populated cannot segment users reliably.

Prefer structured values

Use vocabulary-backed or otherwise controlled values for automation wherever possible. Structured values prevent variations such as:

• Sales Manager
• Sales manager
• Sales Mgr.
• Manager – Sales

Those labels may appear equivalent to a person but behave as different data if they are stored as separate values. Controlled vocabularies also improve imports, API mapping, filtering, and reporting.

Before using a field in a live rule, confirm:

• Who owns the value
• Which system is authoritative
• Whether users may edit it themselves
• Whether an SSO, HR, CRM, or API sync can overwrite it
• Which values are allowed
• How blank or unknown values are handled
• Whether historical users have populated values
• Whether the field is included consistently in every creation and update route

For more detail, see Tags, User Profile, Forms.

Role is data as well as permission

A user's Role can identify an onboarding audience, but Role also controls what the user can do. Do not change Roles merely to make an onboarding rule match. Assign the correct security role first, then use it as a criterion only when the learning requirement genuinely follows that role.

A user can also have more than one relevant relationship or role in a complex platform. Test representative combinations rather than assuming every user has one simple label.

Language and localized training

Language is useful for assigning the correct language-specific Training Activity or presenting localized content. The activity translations or language-related versions remain separate records and can retain independent schedules, prices, participants, and configuration.

Create mutually clear rules—for example, one for Danish and one for English—and define what happens when the preferred language is blank or unsupported. A fallback rule can be appropriate, but its criteria must not overlap unintentionally with the localized rules.

Language targeting is available when the platform has at least two languages. A rule using the platform's default language can still match that default even when the Language field is not exposed on the user's profile. Test this behavior before creating a separate fallback that could overlap.

Country and State/Region

Country and State/Region can support legal, regulatory, tax, or regional-program differences. Use stable profile values and confirm the source system supplies them in the expected format.

Do not infer a compliance requirement from a postal address alone without validating the business rule. Country of residence, work location, legal employing entity, and organization can describe different things.

When Country and State are combined:

• A rule with Country only can match a user in that Country whether or not the user also has a State.
• A rule with Country and State requires the user to have the selected State.
• A user with the correct Country but no State does not match a rule that specifies State.

State must be enabled in the User Profile configuration before it can be selected for onboarding. For SSO, confirm that country codes are transferred in the supported format and mapped to the expected country value.

Organization and suborganization hierarchy

Organization criteria are especially useful in extended-enterprise platforms with customers, distributors, departments, regions, or legal entities.

When Organization is added as an audience attribute, the rule can select from the organizations available on the platform. If a selected Organization has suborganizations, a Suborganizations field also becomes available.

When two or more organizations or suborganizations are selected:

• Enable Any of the organization when membership in at least one selected Organization or Suborganization is sufficient.
• Leave it disabled when the user must belong to all selected organizations or suborganizations.

Use Exclude organization to remove users belonging to the selected Organization or Suborganization from the audience. For example, selecting a parent Organization and one Suborganization and then excluding the Suborganization prevents that local branch from receiving the assignment while users attached only to the parent can still qualify.

Select the intended organizations and suborganizations explicitly and retest the rule when the hierarchy changes. Do not assume that a newly created branch is included unless the saved audience selection and tested platform behavior establish that result.

Organization hierarchy can also affect Storefront visibility, administrative scope, seat allocations, reporting, and manager relationships. Those are separate controls. Matching an onboarding audience does not automatically make every other organization-dependent configuration correct.

Hire date and relative onboarding

Hire date supports audience logic such as:

• People hired before a defined date
• People hired after a defined date
• People at a defined number of days since hire

Use it for staged induction, probation checkpoints, or different legacy/current curricula. Confirm whether the business requirement means calendar days, employment days, or another interpretation, and test around date boundaries and time zones.

A rule based on a specified number of days after hire is evaluated through daily hire-date processing. Before/after-date rules can be evaluated when the Hire date is created or updated and through other applicable user triggers.

Product-based targeting

Where enabled, onboarding can use the Products associated with a user's Organization or Suborganization. The platform must have the organization Product field and the applicable workplace or Product tags configured.

When a user's Organization relationship is created or updated, a published rule can match the Products attached to that Organization according to the rule's trigger configuration. Confirm ownership of the Organization-to-Product mapping before using it for automatic training assignment.

Combine criteria with AND, OR, and exclusions

Logical operators let one rule describe a precise audience.

Understand multiple values inside one attribute

Many audience attributes can contain several selected values. Their internal behavior is separate from the AND or OR connection between different attributes.

• When Any of the... is enabled for a multi-value attribute, the user needs at least one of the selected values.
• When Any of the... is not enabled, the user must have all selected values for that attribute.
• Organization and Suborganization selections use the comparable Any of the organization behavior.
• An Exclude checkbox applies to the selected values for that attribute.

Write the audience in plain language before reproducing it in the rule. For example:

Assign users who are Participants AND Technical Specialists, excluding the Internal Test organization.

Use the available attribute connectors and per-field selection options to reproduce that policy. Do not assume that visually adjacent values create parentheses or another advanced expression that the interface does not explicitly show.

Use a test matrix

For every rule, list representative users before activation.

Test boundary conditions and missing data, not only the ideal matching record.

Choose what the rule should do

Onboarding supports two broad kinds of outcomes:

1. Persistent assignment—enroll in Training Activities or become a member of Communities.
2. Login-presented content—show a Questionnaire, video/playlist, interactive content, text, or document when the user enters the platform.

These outcomes serve different purposes and have different completion, communication, and governance requirements.

Video/Playlist, Interactive content, Text and documents, and Questionnaire are exclusive login-content selections: once one of these content types is selected, other content is not available for that rule. Create separate rules when the same audience needs several independent login-presented items.

Assign Training Activities

Select Training Activity when matching users should become participants in one or more activities.

What happens:

• Eurekos attempts to create the applicable activity enrollment for the matching user.
• A user who already has a signup in the selected activity is skipped, regardless of whether that signup is Registered, Reserved, Cancelled, Expired, or Waiting list.
• Registered activities become available in the participant's learning experience, including the Home screen where applicable.
• The activity's own learning structure, availability, access, schedule, Mandatory deadline, completion, feedback, certificate, and email configuration continue to govern the participant journey.
• The action happens in the background without a participant checkout.
• Notify users can send a direct notification that the user has been enrolled in a new activity.
• Automated Email Workflows remain available for a fuller sequence of welcome, reminder, event, completion, and follow-up communication.

The existing-signup check is important when a former participant has a Cancelled or Expired record. Onboarding does not create a new attempt merely because the old signup is no longer active. Use the appropriate participant reactivation, re-enrollment, or new-attempt process when another participation record is required.

Choose activities that are ready to receive automatic enrollments

Before adding an activity to a rule, confirm:

• The activity is the correct production record, not a template, clone, draft test, old year, or translated sibling.
• Modules, schedules, dates, time zones, instructors, locations, and capacity are ready.
• The activity status and participant availability support the intended experience.
• The Activity Description and title make sense when the assignment appears to the learner.
• Mandatory deadlines are correct for users who may be enrolled at different times.
• Notify users and Automated Email Workflows are configured according to the intended communication journey.
• Certificate, Training Feedback, completion, and re-certification logic are tested.
• Prices and financial follow-up are appropriate for a non-checkout enrollment route.

The onboarding rule does not replace activity configuration

The rule determines who is assigned. The Training Activity determines what the assigned journey does.

For example, enrolling a person through onboarding does not create an Event schedule, reserve an instructor, set a Mandatory deadline, send joining instructions, issue a certificate, or make incomplete modules available. Configure those behaviors on the activity and its modules.

For more detail, see Creating a Training Activity, Automated Email Workflows.

Assign Community membership

Select Communities when matching users should become members of one or more defined Communities.

The Community assignment option is available only when Communities are enabled in Settings → General.

This is useful for:

• A role-based Community of practice
• A customer or distributor support Community
• A regional knowledge-sharing group
• A cohort Community that exists independently of one Training Activity

Community notifications are sent by default unless that behavior is changed. Review the Community's membership and notification configuration before a large profile import or synchronization.

Direct Community assignment versus an activity-connected Community

These are separate designs:

• An Onboarding Rule with Communities adds every matching user directly to the selected Community.
• A Training Activity connected to a Community can add the activity's participants and responsible users through the activity connection.

If the rule enrolls a user in an activity and separately adds the same user to that activity's connected Community, the two paths overlap. Decide which relationship should own membership so that access, notifications, and later administration remain understandable.

For more detail, see Community Connection, Communities.

Present content after login

Use login-presented onboarding content when the user should see or complete information in the platform rather than simply receive a learning-path assignment.

Supported content can include:

Use the preview control on a configured content block to review its presentation. Preview validates the selected material and overlay, but it does not test publication state, audience matching, triggers, recurrence, profile updates, or blocking behavior. Complete an end-to-end test with a matching user through the normal authentication route.

Once Video or playlist, Interactive content, Text and documents, or Questionnaire is selected, another content type is not available in that rule. Use separate rules when the audience needs several independent onboarding popups.

Questionnaires and profile enrichment

A Questionnaire can collect information not supplied by HR, CRM, signup, or authentication. Where its response actions update authenticated user-profile fields, those new values can influence later targeting and workflows.

Design this as a deliberate sequence:

1. The first rule identifies users whose profile needs enrichment.
2. The Questionnaire asks for controlled information.
3. Approved response mappings update the intended user-profile fields.
4. The profile update can make the user match another Onboarding Rule.
5. The second rule assigns the appropriate training or Community.

Test for loops. A repeatedly presented Questionnaire that continually rewrites a triggering field can cause confusing re-evaluation, even when duplicate assignments themselves are prevented.

Treat sensitive answers according to privacy, retention, consent, access, and reporting policies. Do not collect information merely because it could improve targeting.

For more detail, see Introduction to Questionnaires and Common Use Cases, User Profile.

Configure repeated and mandatory presentation

Login-presented content can support two additional behaviors.

Show repeatedly

Use Show repeatedly when the content should return according to a defined frequency. Supported frequencies can include:

• Daily
• Weekly
• Bi-weekly
• Every 6 months
• Every 12 months
• A configured number of days after registration

Appropriate uses include:

• A periodic safety reminder
• A staged onboarding prompt
• A recurring request to confirm information
• Reinforcement of an incentive or product-adoption program

Avoid repeating long or unchanged content unnecessarily. Define the business reason, end condition, and owner before enabling recurrence. Test whether completion suppresses or changes later presentation for the selected content type and configuration.

Users cannot skip and must complete to continue

Enable Users cannot skip and must complete to continue when the selected login content must block further use of the platform until completed. For mandatory video, the Skip action becomes available only after the required viewing has completed; attempting to use another direct page does not bypass the restriction.

Use this sparingly. A configuration, content, accessibility, or integration problem can prevent the complete target audience from proceeding.

Before enabling it:

• Test every required question and validation rule.
• Confirm the content can record completion reliably.
• Verify keyboard, screen-reader, mobile, browser, and language behavior.
• Provide a support route for users who cannot complete it.
• Decide how exemptions and exceptional completion will be handled.
• Confirm the audience does not unintentionally include administrators or service accounts.
• Test login through every relevant identity provider.

Do not confuse two kinds of mandatory behavior

Users cannot skip and must complete to continue applies to content presented through the Onboarding Rule at login. The Training Activity Mandatory feature defines a participant deadline and overdue state for an activity. One does not automatically configure the other.

Manage the rule lifecycle

The Rules tab under Settings → Onboarding lists each rule's Title, Audience, and assigned Content. Use search and filtering when the list becomes difficult to review.

A rule can be:

• Saved as a draft—the rule appears inactive or greyed in the list and is not applied to anyone.
• Published—the rule can run when one of its configured triggers occurs.
• Unpublished—future evaluation is paused without reversing outcomes already added.
• Cloned—a copy provides a starting point for another audience or outcome; review every copied setting before publishing it.
• Deleted—the rule is removed, but registrations, Community memberships, completions, Transactions, and other historical outcomes remain.

Use the rule's More menu to edit, publish or unpublish, clone, or delete it. Publishing a new or updated rule can also offer Apply rule immediately for existing matching users.

Create an Onboarding Rule

1. Open Settings → Onboarding.
2. Create a new rule.
3. Enter a name that identifies the audience and purpose.
4. Define the target audience from available user-profile criteria.
5. Combine attributes with AND or OR, configure Any of the... behavior where available, and apply the relevant Exclude options.
6. Select what matching users should receive: Training Activity, Community, Questionnaire, Video or playlist, Interactive content, or Text and documents.
7. Select the exact activities, Communities, or content records.
8. For Training Activity assignment, decide whether Notify users should send a direct enrollment notification.
9. For login-presented content, add its description or Overlay title and configure recurrence and mandatory behavior as applicable.
10. Preview selected login content where the preview control is available.
11. Enable Apply upon user creation only when the rule should run immediately as matching accounts are created.
12. Recheck the audience, exclusions, selected records, notification behavior, and downstream dependencies.
13. Select Save draft when further review is required, or Publish to activate the rule.
14. If publishing offers Apply rule immediately, choose whether existing matching users should be processed now.
15. Test the applicable first-login, account-creation, profile-update, hire-date, or immediate-application route with controlled users.
16. Verify the actual enrollment, Community membership, or login presentation.

Names should remain understandable outside the editor. For example:

• Employees – Denmark technicians – Safety 2026
• Distributors – Product A – Community access
• New hires – Day 0 – Mandatory profile questionnaire
• Managers – Monthly – Incentive explainer

Avoid names such as Rule 4, New onboarding, or Test final, which do not communicate scope or ownership.

Verify the configuration

Use controlled test accounts to check both who matches and what the rule actually does. Include overlapping rules; a profile update may trigger more than one.

Roll out in controlled stages

When a rule can affect many users:

1. Test in a non-production environment if available.
2. Use a narrowly controlled audience on the live platform.
3. Verify every downstream effect.
4. Expand the audience deliberately.
5. Monitor the first real identity synchronization or import.
6. Keep an owner available to stop future evaluations and correct outcomes.

Because assignments are not automatically reversed, preventing a wrong match is safer than relying on cleanup.

Understand downstream Training Activity behavior

Capacity and waiting lists

Onboarding is subject to applicable seat behavior. If the activity or the user's organization has no available allocation and waiting-list behavior applies, the user can be added to the Waiting list instead of becoming Registered.

That means a successful rule evaluation does not always mean immediate training access. Check the participant status:

• Registered—the user has the active signup and applicable access.
• Waiting list—interest is recorded, but the user is not yet registered and does not receive registered access.

Configure waiting-list communication separately and avoid telling all matched users that a place is confirmed.

For more detail, see Registration Details and Capacity, Waiting list.

Nested Training Activities

If onboarding enrolls a user in a parent Training Activity that contains an Existing Training module with automatic enrollment enabled, the parent enrollment can cause a second enrollment into the nested activity.

The nested activity remains independent. It can have its own:

• Capacity and Waiting list
• Schedule and time zone
• Availability and access expiration
• Participants and communication
• Completion, feedback, certificate, and price

Automatic nested enrollment applies to new qualifying parent enrollments according to the nested configuration. Test the complete chain; seeing the parent assignment does not guarantee that the child produced the same status.

For more detail, see Existing Training (nesting).

Automated Email Workflows

When a rule assigns a Training Activity, select Notify users if the participant should receive the direct enrollment notification. Leave it cleared when communication will be handled another way.

Use Automated Email Workflows on the assigned activity when the participant needs a broader communication journey, such as a welcome message, preparation instructions, Event reminders, deadline notices, completion messages, or follow-up. The direct notification and the activity workflows are separate, so review them together rather than assuming that one replaces the other.

Consider:

• One user may receive several activities from one or more rules.
• Each activity can have several workflow rules.
• A nested child activity can have its own workflow.
• Calendar Events, Assignments, approvals, feedback, and certificates can generate additional communication.
• Community assignment and login-presented content have their own participant experience.
• An order-confirmation email is not sent for a Training Activity assigned through onboarding.

Review the complete journey to avoid sending a burst of messages after a large user import or identity synchronization. Confirm platform and mail-provider sending capacity for the maximum population.

For more detail, see Automated Email Workflows, Email Sending.

Participation approval and self-enrollment restrictions

Onboarding is an administrator-designed assignment route. It is not the same as a participant browsing the Storefront, requesting a place, satisfying self-enrollment criteria, or completing checkout.

Do not assume that a configuration intended specifically for self-enrollment will turn the onboarding assignment into a request or participant choice. Conversely, activity-level availability and access controls can still shape what an enrolled participant can open and when. Test the exact restriction type with the onboarding route.

Use participation approval when a person should actively request training and an approver should decide. Use onboarding when a matching profile should result in an automatic assignment.

Mandatory deadlines, access expiration, and completion

If the selected activity has Mandatory enabled, its deadline is calculated from the activity's configured method. A deadline relative to enrollment can therefore differ for each onboarding participant.

Access expiration and completion behavior remain activity-level concerns. Verify that a person is not assigned after the useful access window, given an impossible deadline, or enrolled in a delivery that has already ended.

Certificates and re-certification

Onboarding enrollment does not issue a certificate by itself. The selected activity's certificate criteria determine issuance after the required outcomes are achieved.

If the activity supports re-certification, automatic onboarding into the activity and the certificate's renewal attempt logic are separate automation systems. Design them together so a user is not given a confusing duplicate path or an inappropriate new initial enrollment.

For more detail, see Re-certification, Certificates.

Understand commerce and Transaction behavior

An Onboarding Rule does not present checkout. The user is assigned in the background and cannot select a payment method, enter a Coupon, approve a price, or pay during that action.

If the selected Training Activity has a standard price:

• The applicable amount can appear on the participant/signup record.
• Enrollment-related Transaction evidence can be created according to the platform's transaction model.
• No interactive payment has been collected through onboarding.
• No order-confirmation email is sent for the onboarding assignment.
• Invoicing, reconciliation, or settlement must be handled as a separate approved process, such as an export, API, ERP, organization agreement, or manual financial workflow.

Do not use onboarding for a commercial offer that requires the participant to choose, accept terms, apply a discount, buy an Additional Product, select a payment method, or complete payment. Use a Storefront, invitation, promotion, manager, or other guided enrollment route appropriate to the process.

Before assigning a priced activity automatically, document:

• Who is contractually responsible for payment
• Whether the amount is informational, internally allocated, invoiced, or covered by an agreement
• Which organization and cost center should be used
• How finance distinguishes paid, free, allocated, and unsettled records
• How exceptions and cancellations are corrected

For more detail, see Enroll and register participants, Price Manager, Transactions.

Multiple rules, overlapping audiences, and idempotency

A user can match several Onboarding Rules. This may be intentional—for example, one rule assigns general employee induction and another assigns country-specific compliance.

Problems arise when two rules represent the same business requirement or assign overlapping outcomes. For Training Activities, a user is skipped when any signup for the selected activity already exists, including a Registered, Reserved, Cancelled, Expired, or Waiting-list signup. The rule does not create a new participation merely because the existing record is inactive.

Other onboarding content has its own repeat and duplicate behavior. In particular, Apply rule immediately can present applicable onboarding content again, so use it only after checking the selected content and the affected population.

Overlapping design can still create:

• Unclear ownership
• Repeated evaluation
• Duplicate or clustered communication
• Redundant Community-assignment paths
• Confusing audits and troubleshooting
• Unintended combinations of mandatory login content

Maintain a rule inventory showing audiences and outcomes. Before creating a rule, search for every activity, Community, field, and population it will use.

Do not rely on rule order to resolve conflicts unless the interface and tested behavior explicitly define an order. Design rules so the audience logic is correct independently.

Change, unpublish, clone, or retire a rule

Treat a rule change like a change to live automation.

Before changing audience logic or selected content:

• Identify which profile updates and imports are scheduled.
• Estimate how many users could match.
• Identify overlapping rules.
• Review activity capacity, dates, communication, and financial impact.
• Test both newly created and existing-updated users.
• Record the change, owner, reason, and approval.

Use the rule's More menu to manage its lifecycle:

• Edit changes the audience, content, or options. Treat a published-rule change as a change to live automation.
• Unpublish pauses the rule. It no longer applies while unpublished, but it remains available for review and later editing.
• Clone creates a separate starting copy. Review its title, audience, content, and trigger options before publishing it.
• Delete removes the rule. Confirm the target carefully and preserve any evidence required for governance or support.

Saving a rule as a draft does not activate it. A draft appears inactive and applies to nobody until it is published.

Unpublishing or deleting a rule prevents future outcomes from that rule; it does not undo outcomes already added. Previously enrolled participants, Community memberships, completions, certificates, Transactions, and collected responses require their own governed correction where appropriate.

Likewise, making an audience narrower does not remove users who qualified under the former logic. If removal is a business requirement, plan it as a separate operation with audit evidence and appropriate participant communication.

Realistic use cases

Troubleshooting