Understanding Rules

A rule is an automated instruction that tells RoleLogic what to do when certain conditions are met.

Basic Concept

Every rule has two parts:

1. IF (condition): When should this happen?
2. THEN (action): What should happen?

Example:

IF a member has "Server Booster" THEN add "VIP"

Once active, RoleLogic automatically adds VIP to all boosters—current and future.

Parts of a Rule

Condition (IF)

Defines which members the rule applies to:

• Condition type: How to check roles (has some, has all, lacks some, etc.)
• Roles to check: Which roles to look for
• Threshold: For counting conditions (at least 3, exactly 2, etc.)

You can add up to 9 additional conditions with AND logic.

See all condition types →

Action (THEN)

Defines what happens when conditions are met:

• Add roles: Give members one or more roles
• Remove roles: Take away one or more roles

You can combine both in a single rule.

Learn about actions →

Priority

Determines the order rules run:

• Priority 0 runs first
• Priority 1 runs second
• And so on...

Priority matters when rules depend on each other:

Rule A (priority 0): If has "Trial" → add "Member"
Rule B (priority 1): If has "Member" → remove "Trial"

Rule A runs first, then Rule B.

Status

Rules can be:

Status	Meaning
Enabled	Active and processing
Disabled	Saved but not running
Pending	Queued, waiting for first sync
On hold	Saved, but withheld from the bot until you confirm it or fix a problem
Changes waiting	Running as it was; an edit you saved waits for your confirmation
Stopped	Auto-stopped because its changes were being undone (see Safe Apply)

How Rules Process

Trigger Events

Rules evaluate when:

• A member joins or leaves
• You or a moderator changes roles
• Another bot changes roles
• Discord changes roles (boosters)
• RoleLogic's own rules make changes

Processing Flow

1. Event occurs (role change, member join, etc.)
2. RoleLogic checks all enabled rules in priority order
3. Matching rules execute their actions
4. Cascade check: If changes were made, rules are checked again
5. Repeat until no more rules match (max 100 passes)

Cascading

One rule's action can trigger another rule:

1. Member gets "Level 10"
2. Rule A fires: "If Level 10 → add Premium"
3. Rule B fires: "If Premium → add VIP-Access"
4. No more rules match—done

This creates powerful automation chains.

Background Sync

RoleLogic also runs a continuous background scan to catch changes missed by event-driven processing. It runs about every 30 minutes on Free servers and about every 2 minutes on Premium servers, with Premium also scanning large servers far faster per pass. Event-driven rule processing takes about 10 seconds on Free or 1.5 seconds on Premium; the sweep is a safety net.

Creating a Rule

1. Click "Add New Rule" in your dashboard
2. Set condition: Choose type and select roles
3. Set action: Choose add or remove, select roles
4. Add description: Name your rule clearly
5. Save: RoleLogic estimates how many members the rule would change. Ordinary rules go live about a minute later; a rule that would change many members at once waits for one confirmation click (see Safe Apply)

Safe Apply

Most rule mistakes are small — a condition typed the wrong way round, a remove where an add was meant. What makes them expensive is scale: one wrong rule can touch thousands of members before anyone notices. Safe Apply is how RoleLogic keeps a wrong rule from becoming a wrong server.

Estimate before apply

Every save is a dry run first. The bot works out, from the live member list, exactly which members would gain or lose which roles under the new rule set, and the dashboard tells you:

• how many members are affected, and how many role additions and removals that is;
• how many members already match — the conditions apply to them, and their roles are already as the conditions want them, so nothing is written;
• which roles, largest first, with the share of that role's holders it would touch;
• whether the change goes live on its own or needs your confirmation, and why.

The numbers are for what your change does. Each member is evaluated under the role conditions running now and under the new set in the same pass, so a change counts when it exists only because of your edit — even when it lands on a different role condition. That matters when conditions share a role: the first one to act on a role holds it, so switching a condition off, narrowing it or moving it down can hand its members to the next one, whose else branch may then remove the role. Changes that were already waiting before your edit (in a paused server, or from another save still in its settle window) go out with it; the dialog counts them in the totals and says how many there are, and they don't count toward the thresholds.

A condition that has already run changes nobody, and the dialog says so — but 0 changes is not 0 members. The members it still applies to are counted separately: the member tile shows how many already match, each role line shows how many already have (or already lack) that role beside the number it would change, and a destination server's line shows the same for that server. Members who already match are never written to and count toward none of the safety thresholds; only the changes do.

There is nothing extra to run. The save message gives the number of members, and until an ordinary change goes live the status bar keeps its estimate beside the countdown. To see it before saving, use Check impact next to Save Changes in the rule editor. It measures exactly what Save would — the rule set in the order the save leaves it, against what runs now — and tells you what the save would do: go live, wait for your confirmation (naming any other role condition it would pause too), or be refused (a draft that forms a loop with other role conditions, or names a role the bot cannot manage, cannot be saved). If you keep editing while it checks, the dialog says the numbers are for the earlier draft and offers Check again. A draft that switches the condition off shows what the other conditions do without it.

Roles the rule changes in other servers are counted too, against each destination server's current members: a member counts only if they are in that server and would really gain or lose the role there. Those changes are part of the headline numbers, and below the role list there is one line per destination server (Also in Lounge: +12 / −3). If RoleLogic cannot read a destination server's members at that moment — its gateway budget for member lists is spent, or Discord does not answer in time — that server's numbers are an upper bound: the whole estimate is marked Estimate and Things to double-check names the server. If RoleLogic is not in the destination server, or the role there has been deleted, the dialog says so and those changes are not counted — it identifies the server by name, or by its id when RoleLogic is no longer a member. A role the bot cannot manage there is counted and flagged, since Discord will reject the change.

Auto, or confirm

A change goes live by itself after a short settle window (about a minute — time to catch a typo) when it stays under the server's thresholds. It waits for your confirmation, shown to you for a single informed click, when it would:

• remove a role from about 3% of the server or more (at least 10 members, and at most 100 before trust widens it);
• remove a role from a quarter or more of the members who hold it (at least 10), here or in a destination server;
• add a role to a large share of the server;
• grant a role that carries moderation permissions, here or in a destination server (judged by that server's permissions);
• remove roles in a rule that matches every member or has an else branch — the classic sign of an inverted condition.

Each limit is per role, across every role condition that changes it: two conditions each removing a role from 40 members count as 80.

While a change waits, what runs is what ran before it:

• An edit to a role condition that is running waits beside it. The condition keeps running exactly as it was — including the roles it keeps other conditions away from — until you apply the edit, so nothing the edit would change happens early, on it or on any other condition. The rule editor opens your saved edit under Changes waiting for your confirmation, with Review and apply and Discard changes; discarding drops the edit and leaves the condition exactly as it is. Saving again replaces the waiting edit and is checked afresh. This covers switching a running condition off, too: it keeps running until you confirm. An edit that leaves the condition in its place keeps it there even if other conditions are added or removed meanwhile.
• A new role condition, or an edit to one that is not running (switched off, or already on hold), is saved and withdrawn from the bot until you apply it — without it, nothing it would cause can happen, and members keep the roles they have.

Deleting a role condition takes effect at once. If that hands members to other conditions over the limits, the conditions it reaches are put on hold, and RoleLogic checks that holding them does not hand members on in turn; if it would, every condition that changes the same roles waits instead. The review dialog lists every role condition that waits, and whether it keeps running meanwhile. A condition paused only because a deletion reached it goes back to work by itself when that confirmation is replaced by a newer change, if letting it run is then within the limits. Resuming a paused role condition that turns out to be over the limits puts that condition back on hold, exactly as it was.

Nothing a held change does happens until you press Apply in the review dialog. An edit is written at that moment, with the same checks as a save: the roles it uses must still exist and be ones RoleLogic can manage, you must still manage every server it reaches, and it must not duplicate another condition or close a loop. If any of that changed, it is refused and keeps waiting. If other role conditions changed after the numbers were shown, Apply checks again first: a change now under the thresholds goes ahead — unless it moves its condition, whose new place may now sit among different conditions — and otherwise the dialog shows the current numbers for you to review. An edit that reaches another server is dropped if that server is unlinked from this one while it waits. Servers with a history of clean deployments earn wider thresholds over time; a safety stop, a paused staged rollout or an undo resets them.

A paused server stays paused when you save: nothing goes live until you press Start Live, which checks the whole set first. A server whose rules were stopped by a safety stop starts again on the next save or delete, so that change is checked the same way as Start — everything the rules would do, not only your edit — and what the check names waits for your confirmation, as it would on Start.

If the bot cannot estimate a change at that moment — while it restarts, for instance — the change is held the same way instead of going live unchecked. The review dialog says the impact could not be checked: test the rule first, or apply it if you are sure it is right. This only happens to a change someone is making (a save, Start Live, a resume): role conditions that are already running are never paused because a check nobody asked for could not run.

When RoleLogic's own role moves up, or it is given Manage Roles, roles it could not change before come within its reach, and role conditions that were waiting on them would catch up all at once. RoleLogic measures that catch-up first. If it crosses the thresholds above, the role conditions involved are held for your confirmation, like a save, and the review dialog says why; otherwise, or if it cannot be measured, they keep running. Reordering, renaming or recolouring roles without moving any of them past RoleLogic's role checks nothing.

Applying in stages

The largest changes are applied to a small slice of members first — staff before everyone else — and then held for a few minutes. If moderators start undoing those first changes, RoleLogic pauses instead of continuing. You can also press Continue now to skip the wait, or Stop at any time. Roles the rule changes in other servers are part of the first slice and of the progress count, like the local ones.

Undo

Every role the bot adds or removes is recorded. For 24 hours after a deployment finishes you can press Undo changes to put every role back — except roles that have changed again since (by a moderator, another bot or another rule), which are left alone. Roles the deployment changed in other servers are put back too. The rules that made the change are put on hold so they do not redo it.

When a deployment stops early

A deployment that cannot finish says why in the status bar, in plain words: the role conditions changed between the check and the start, another deployment was still running, the member list could not be read from Discord, and so on. The bot's exact message is behind the info toggle. When nothing was applied, the role conditions are still live, and the background sync applies them at its normal pace — without the staged rollout or Undo. To run the deployment again with those, press Pause Live and then Start Live. Once you have read the row, you can dismiss it.

When a rule is put on hold by the bot

Besides the impact gate, the bot itself holds a rule when it can no longer act on it safely:

• Hierarchy — the bot lost permission over a role the rule manages. Move the bot's role above it, then press Resume.
• Role deleted — a role the condition depends on is gone. Edit the rule, then resume.

The bot never holds a rule just for changing many members. Once a change has passed the checks above, large bursts — an event role handed to hundreds of members at once — run at your plan's normal pace.

Combining Conditions

Add up to 9 additional conditions with AND:

IF has "Verified" AND has "Level 5" AND lacks "Muted" THEN add "Trusted"

All conditions must be true.

Combining Actions

Use "Add Combined Action" for add AND remove:

IF has "Promoted" THEN add "Staff" AND remove "Trainee"

Tips

• Clear names: "Remove Guest when Verified" not "Rule 7"
• Start simple: Test basic rules before complex chains
• Use priority intentionally: Think about which rules should run first
• Test first: Use the sandbox before going live

---

Next Steps

• Condition Types — All 9 ways to match members
• Actions — Add and remove roles
• Testing Sandbox — Test safely before going live