Building Your Sale · JBFOne Knowledge Base
Understanding Rules in JBFOne
Rules give you control over how your consignor registration experience behaves. Rather than applying the same flow to every registrant, you can use rules to show or hide questions, adjust fees, limit ticket access, control schedule visibility, and more — all based on conditions you define. Once a rule is active, it runs automatically every time someone registers for your sale.
What this article covers
- What rules are and how they work
- The three parts of every rule
- Where rules live in your event setup
- What each rules section can do
- Tips for building rules
- How to get started
What a Rule Does
A rule watches for a specific condition during registration and triggers an action when that condition is met.
Think of it as an if/then instruction: if this is true about the registrant, then do this.
- Rules run automatically — no manual intervention once they are active
- A single rule can trigger multiple actions at once
- Rules only fire when their conditions are met — registrants who don’t match the condition are unaffected
- You can have as many rules as your sale needs, across as many sections as apply
- Pay attention to conditional vs always settings. (conditional items appears/applies IF they meet the criteria in the rule, always shows the item UNLESS criteria is met to hide the rule)
The Three Parts of Every Rule
Every rule in JBFOne — regardless of which section it lives in — is built from the same three components.
1. Rule Name and Settings
2. Conditions
3. Then Do This (Actions)
Rule name and settings
- Give the rule a clear, descriptive name so it is easy to identify later
- Set the Evaluation order — a number that controls the sequence rules are checked (lower numbers fire first)
- Active is checked by default — uncheck to pause a rule without deleting it
- Stop after this rule — check this if you want the system to stop evaluating additional rules once this one fires
Conditions
Conditions define who the rule applies to. Each condition is built from four parts:
- Context — what type of information to look at (e.g., prior registration profile history, answer to a question, date/timing)
- Field — the specific data point within that context (e.g., has_been_seller, total_events_attended)
- Operator — how to compare it (equals, does not equal, contains, greater than, is empty, etc.)
- Value — what to compare it against (e.g., true, a number, a specific answer)
Conditions can be combined using:
- AND groups — all conditions in the group must match
- OR groups — any condition in the group must match
Pro Tip: You can mix AND and OR groups in the same rule. This lets you target very specific registrant profiles — for example, consignors who have sold before AND attended more than three events, OR who registered using a specific tracking link.
Then do this
This is the action the system takes when conditions are met. The actions available depend on which section you are working in — a rule in Questions can show or hide a question, a rule in Fees can waive or adjust a fee. The structure is identical across all sections. Only the available actions change.
Where Rules Live
Rules are accessible in two places.
Inside each checklist section
Every section that supports rules has a Rules tab alongside the Setup tab. This is where you create, edit, and manage rules for that specific section. Rules built here only affect that section.
The sections that currently support rules are:
- Questions — show or hide questions based on registrant history or prior answers
- Schedule — show or hide schedule slots based on registrant criteria
- Fees — waive, adjust, or apply fees based on registrant history
- Tickets — show, hide, block, or modify ticket access based on conditions
In the Rules checklist item
The Rules item at the bottom of your event checklist is a central view of every rule across your entire event. From here you can:
- See all rules in one place
- Filter by section to focus on a specific area
- Review, edit, or manage rules without navigating into each section individually
Pro Tip: Build rules inside the section where they belong, then use the Rules checklist item to do a final review of everything together before you go live.
Starting Points and Custom Rules
When you add a rule, JBFOne offers pre-built starting points — templates designed around common use cases. These give you a head start by pre-filling the rule structure so you only need to fill in the specifics.
- Templates are a fast path for the most common scenarios
- Start from scratch — build a custom rule is available when your use case isn’t covered by a template
- Both paths use the same rule builder — templates simply pre-populate the fields
Note: A Questions Library is coming soon. It will allow you to build Rule Templates using questions from your library, making it even faster to set up consistent registration logic across your sales.
A Note on Evaluation Order
When multiple rules exist in a section, JBFOne evaluates them in the order you define.
- The Evaluation order field on each rule controls the sequence — lower numbers are evaluated first
- If two rules have the same evaluation order number, results may be unpredictable — keep them unique
- Enable Stop after this rule on any rule where you want evaluation to stop once a match is found
Pro Tip: Use evaluation order intentionally. Put your most specific rules first (lower numbers) and your broadest or catch-all rules last. This prevents a general rule from overriding a targeted one.
Tips for Building Rules
Before you build
- Know your questions, fees, tickets, and schedule slots first — the rule builder only references what already exists. Building rules before your setup is complete means rebuilding rules later.
- Name everything clearly before you start. A rule called “Rule 1” is useless at 11pm the night before your sale opens.
- Sketch the logic on paper first for anything complex. If/then thinking is easier to catch errors in before you’re inside the builder.
Building conditions
- Start with the simplest condition that gets the job done. You can always add complexity later — you can’t always untangle it.
- Coupon codes and UTM Source values are case-sensitive. What you type must match exactly what was distributed or set in the tracking link.
- AND groups narrow your audience. OR groups broaden it. Mixing them gives you precision — but map it out first so you know which group is doing what.
- User group membership conditions are powerful for building segmented experiences — but the groups have to be populated first, either manually or by another rule.
Priority order (Evaluation order)
- Think of the Evaluation order field as a priority queue, not just a number. The lower the number, the higher the priority. What needs to happen first?
- Use 10, 20, 30 spacing. You will add rules you didn’t plan for.
- If two rules conflict and you’re getting unexpected behavior, check their Evaluation order — the lower-priority rule may be overriding the higher-priority one.
- Use Stop after this rule intentionally. It’s not always the right call, but when you need it, you really need it. Three common JBF scenarios where it matters:
- Early registration window for returning team members — once the rule shows the exclusive slot, you don’t want subsequent rules re-evaluating visibility for that same slot.
- Coupon code fee waiver — once the coupon match fires and the fee is waived, stop evaluation so loyalty or group-based fee rules don’t stack or interfere.
- First-time seller ticket access — once the correct ticket type is shown, stop evaluation so a returning seller rule further down doesn’t also fire and show both ticket types.
Actions
- You can stack multiple actions on one rule. One condition trigger can show a ticket, add to a group, and send an email simultaneously.
- Add to group is underrated. Sorting registrants into groups during registration opens up targeting options for future rules and communications.
After you build
- Use the Rules checklist item to do a final review of everything together. It’s easy to miss conflicts when you’re building section by section.
- Test in the JBFOne Simulator before going live. Build a rule, register as a test consignor, and verify the behavior is what you intended.
- If a rule isn’t firing as expected, check: Is it Active? Is the Evaluation order correct? Does the condition data actually exist for your test registrant?
- Document your rules somewhere outside JBFOne — a simple notes doc with rule names and what they do. When you’re troubleshooting at 11pm, you’ll thank yourself.
Rules are one of the most powerful tools in JBFOne for personalizing the consignor experience. Once you understand the structure, every new rule follows the same pattern.
Next Steps
- LINK TO TICKETS RULES ARTICLE
- LINK TO SCHEDULE RULES ARTICLE
- LINK TO QUESTIONS RULES ARTICLE
Last Updated: SW — 06/03/26