Part D · Reference¶
Lookup material, and the question you will ask most often.
D1 · Glossary¶
- Contact. One person in the loyalty database: a name, a mobile number and/or email address, a date of birth, and the groups they belong to. Created on first app sign-in, through a registration source, or claimed from a physical loyalty card at the till (A2).
- Group. A node in the CRM's group tree. An ordinary or society year-managed group has members and can have children; membership is read upward, so a member of a child group is also treated as a member of every ancestor above it (A3, A4).
- Entitlement pool. A group with no members, and none allowed beneath it either. Its offers are restricted to it exactly like any other group's, but the only way a person gets one is an individual grant (A4, A5).
- Grant. The act — and, loosely, the record it creates — of giving one contact the right to use one of a pool's offers: a number of uses, a validity period and a display reason, all read off the pool (A5, B3).
- Entitlement. What a grant is once it exists: the record on a contact's Entitlements tab that says they may use a particular offer, how many times, and until when. Granting is the action; the entitlement is what results.
- Offer. The CRM's copy of a deal from the POS: a record carrying its own visibility window, its restriction groups, whether it has been built and published, and a usage limit (A1, B4). Never created directly in the CRM.
- Deal. The POS-side thing an offer is imported from. Set up in the POS, not in the CRM (A1).
- POS. The point-of-sale system used at the till. Deals, the Publish to App tickbox that decides whether customers see them, and loyalty-group restrictions are all configured there (A1).
- Venue. A single pub or site. Deals are set up per venue in the POS, and the import (A1) works through the venue list one at a time.
- Registration source. A campaign link or QR code a contact arrives through when they sign up, which can add them to one or more groups at that moment without anyone adding them by hand (A2).
- Society year tree. A society's own branch of the group tree: the society group and the year groups beneath it, built and rolled over automatically by the academic-year clone. Its shape — name and parent — cannot be hand-edited; its operational settings can (A4, B2).
- Preview reviewer. A contact placed in the one group id configured as the environment's reviewer group. A reviewer sees every preview offer in the app that has not yet ended, regardless of group or grant, so a deal can be checked over and signed off in the POS before it reaches anyone else (A6, B4).
D2 · Entitlement source types¶
Every entitlement pool (A4, B3) carries one of six types, chosen from Entitlement Pool Type on the group form. The type is a label only — it drives what the Entitlements page and a pool's "View all… grants" link filter by, and nothing else about how a grant behaves (B3).
| Label shown in the CRM | What a filtered link carries | What it implies |
|---|---|---|
| Manual | Manual |
The default — a one-off entitlement an admin decided to hand out, with no more specific category. |
| Birthday | Birthday |
A pool used for a birthday offer — the display reason is where "Happy Birthday!" (A5) actually gets typed. |
| Prize / giveaway | Prize |
A pool built for a competition or prize win. Nothing restricts it to any one giveaway tool — it is a label, like every other row here. |
| Campaign | Campaign |
A pool tied to a specific marketing campaign, distinct from an everyday manual grant. |
| Sign-up | SignUp |
The type behind sign-up offers — the ones the bulk Verify action releases to a newly verified contact who arrived through a registration source (B1, A2). |
| VIP | Vip |
A pool for a VIP-style one-off, as distinct from an ordinary VIP group's offers, which reach people by membership rather than by grant (A6). |
The label and the name behind it are not the same word.
"Prize / giveaway" and "Sign-up" are the wording for people; Prize and SignUp are what a filtered Entitlements link carries in its web address, and what the page filters on. If you are working from a link someone has pasted into a support ticket, match it against the middle column above, not the label.
D3 · Field reference¶
Group fields¶
| Field | What it does | If left blank |
|---|---|---|
| Name | The group's display name, everywhere it appears — tree, search, every picker. | Required; the form will not save without one. |
| Parent Group | Where the group sits in the tree (A3) — everything above it is inherited by its members, and it inherits nothing from below. | The group becomes a root: nothing above it, and nothing for it to inherit (B2). |
| Stop Date/Time | When the group retires. Once it passes, the group disappears from the tree, search and every picker entirely (B2). | The group never retires on its own; it stays live indefinitely until someone sets a date. |
| Require Photo ID | Whether a member of this group needs a photo on file (B1). | No requirement from this group specifically — a contact can still need a photo because of a different group they also belong to. |
| Hidden | Whether the group is left out of the tree, search and every picker entirely. Not exposed on the group form — something else in the system sets it (B2). | Not applicable; it is not a field you fill in. Every group created here defaults to false (visible). |
| Entitlement Pool Type | Turns the group into a pool of the chosen type (D2), restricted exactly like any group's offers but with no members. | Left on "Not a pool": an ordinary group with members, whatever the other three entitlement fields hold (A4, B3). |
| Uses Allowed | How many times each grant this pool issues can be redeemed. Ignored entirely while the group is not a pool. | Defaults to 1. Typing 0 does not stick — 1 is quietly stored instead, so a pool's grants always allow at least one use however this field is set. |
| Validity (Days) | How many days a grant from this pool stays live, counted from the moment it is granted. | The grant instead runs on the offer's own visibility window (A5, B3). |
| Display Reason | The text appended after "Just for you" on the offer card (A5). | The card reads plainly "Just for you", with nothing appended. |
Offer fields¶
None of these are typed into the CRM — every one is set by the import from the deal in the POS and rewritten on the next run (A1, B4). "If left blank" below means left blank on the deal in the POS, not on a CRM form.
| Field | What it does | If left blank |
|---|---|---|
| Name | The offer's display name, in the CRM list and on the customer's offer card. | No app copy in the POS yet: stored as Untitled deal followed by the POS deal id, so it can still be found (A1). |
| Description | The offer's marketing copy. Also drives Is Built (B4). | Is Built shows red. For an offer with no restriction group, this also means it reaches nobody until it is written (D4) — a group-restricted or pooled offer is unaffected by a blank description. |
| Visible From / Visible To | The offer's visibility window, taken from the deal's own start and end times in the POS. | Visible To left unset in the POS is stored as never-ending rather than as a blank — the offer does not expire on its own until the POS sets an end date. Visible From always carries a value; there is no blank case for it. |
| Usage Limit | How many times the offer can be used. For a pool-held offer this is a different, global cap — see the warning in B3. | No cap: unlimited redemptions from anyone the offer reaches. |
| Groups (restrictions) | The groups the offer is restricted to, read from the deal's loyalty groups in the POS and matched against the CRM's own group ids. | No loyalty groups on the deal in the POS: the offer is Public and reaches anyone once published and built. See D4 for what happens when the POS names a group that does not resolve — the CRM's Groups column can read "Anyone" without the offer actually being public. |
D4 · Why isn’t this offer showing?¶
Work through this list top to bottom. It does not assume you have read anything else in this guide, though most of these points are covered in more depth elsewhere and cross-referenced as you go.
- Is Publish to App ticked on the deal in the POS? If not, the deal is imported but withheld from every customer — only a preview reviewer sees it (see below). This is the most common cause, and it is fixed in the POS, not the CRM. Note this is a separate tickbox from the deal's till visibility: a deal can be live at the bar with Publish to App unticked, and customers will not see it.
- Is the offer inside its visibility window? Check the from and to dates, in CRM → Offers.
- Is it built? Check the Is Built dot on the Offers screen. This only matters for an offer with no restriction group — look at its Groups column first: if it names one or more groups, skip this step, since a group-restricted or pooled offer reaches its audience even with no description written yet. If the Groups column reads "Anyone", an unbuilt offer really does reach nobody. If it is built and Groups still reads "Anyone" but nobody can see it, skip to the mirror-image section below — the offer's groups may have failed to resolve on import.
- Is it restricted to a group? If so, is the customer in that group — or in any group beneath it? Remember membership is read upward: someone added two or three levels down still counts as a member of everything above it.
- Is it in an entitlement pool? That is, is the restriction group from the step above actually a pool (D1, A4)? Then nobody sees it without an individual grant, however well they match everything else.
- Has their grant expired or been used up? Check uses consumed against uses allowed, and the valid-to date — whichever of the grant's own dates or the offer's own dates applies (A5).
- Has the customer finished signing up? An unverified contact, or one who has not confirmed they are 18 or over, is redirected to finish that before they can reach the Offers or VIP page at all. This is a whole-app gate, not a per-offer check — it explains a customer who cannot see anything on those pages, not one who sees other offers but not this one. If other offers are showing fine for this customer, this is not your answer.
The mirror image: an offer with no restriction that still reaches nobody¶
The import matches every loyalty group the POS sends against the CRM's own group ids, and only creates a restriction for the ones that match (B4). What it does not do is work out again whether the offer is Public to match. Public is set from the loyalty groups the POS names — whether it named any group at all — before that matching happens. So if a deal in the POS is restricted to a group that no longer exists in the CRM, the offer gets no restriction for that group, because it does not resolve — but the offer is still marked not Public, because the POS did name a group and the import has no way to know that name was a dead end.
The result is an offer that is neither public nor properly restricted.
The CRM's Groups column reads "Anyone" — it lists actual restrictions, of which there are none — but the offer is not Public either, so it reaches nobody at all, group member or not. If a deal is restricted in the POS and nobody can see it, not even someone in the group it is supposedly aimed at, check that every loyalty group on that deal in the POS still exists as a group in the CRM before assuming the offer is simply public and something else is wrong. Where a deal names more than one loyalty group and only some resolve, the offer is genuinely restricted to whichever ones do — the others just lose their audience silently, with nothing on the offer or in any log to say a group went missing.
The other mirror image: someone sees an offer nobody else can¶
A preview reviewer (D1, A6) sees every preview offer that has not yet ended regardless of group or grant — overriding every check in the list above, for as long as the offer is Awaiting sign-off.
Check whether they are a preview reviewer before treating it as a bug.
If someone reports they can see an offer nobody else can, and no group membership or grant explains it, check whether they are in the configured reviewer group. The likely answer is that they are looking at exactly what a reviewer is meant to look at: a deal not yet app-visible in the POS. Once that deal is signed off and published, the exemption stops applying, and the reviewer sees it — or not — by the same three routes as anyone else (A6).
Screens change; the concepts in Part A do not. Every page here shows when it was last updated, at the foot of the page — trust that date rather than a printed copy.