Sooner or later every attraction has to tell someone they can’t come back. Maybe it was harassment of staff, a theft from the gift shop, or a repeated safety problem near the animals. Leadership makes the call, and then someone asks the admin: “Can we put that in Altru so the desk knows?”
You can, but no single field in Altru is labeled “banned.” You build the flag yourself from the general-purpose tools Altru gives you, and the hard part is making sure the person at the register actually sees it at the right moment. Below are the options, what each is good and bad at, and the policy decisions to settle before you touch a record.
Settle the policy before the data
A ban flag is a sensitive record about a real person, and staff, auditors, or the person themselves may eventually read it. Agree on a few things with leadership first:
- Who can approve a ban and who can lift one. The admin should be recording decisions, not making them.
- What gets written down. Stick to facts: the date, a short neutral description of the incident, who approved it, and how long it lasts. Leave out opinions and diagnoses. A good test is whether you’d be comfortable if the person requested a copy of their record.
- Duration. Permanent, one year, until a meeting with management? An end date makes the flag much easier to maintain.
- What happens to existing relationships. If the person is a current member or donor, decide whether the membership is cancelled and refunded, left to lapse, or kept. That’s a leadership and legal question, not a data one.
- Who should see the details. Front-line staff usually need only “do not admit, call a manager.” The full incident story can live somewhere with tighter access.
Ways to flag the record in Altru
A constituent attribute
Attributes are the most structured option. Create an attribute category such as “Admission restriction” with a short code table (for example, “Do not admit” and “Manager approval required”) and use the attribute’s start and end dates for the duration. Because it’s structured, you can query on it, put it in a smart field, and report on how many active restrictions you have.
The weakness is visibility. An attribute sits on the constituent record, and cashiers selling a quick daily-sales ticket often never open the record at all. An attribute alone tells your data team; it doesn’t necessarily tell the desk.
A note on the constituent record
Notes are where the narrative belongs: what happened, who approved the ban, and a reference to any incident report. Keep the note factual and dated. Notes are hard to query and easy to miss, so treat them as the supporting documentation behind a structured flag, not the flag itself.
An alert or pop-up message
What the desk really needs is a message that appears when the record is pulled up during a sale or a membership lookup. Depending on your Altru version and configuration, there may be a way to surface constituent-level alerts or notes during transactions. We aren’t going to guess at the exact behavior here, because it varies and matters a lot for this use. Before you rely on it, test in your sandbox: flag a test constituent, then try selling them a daily-sales ticket, an advance-sales order, and a membership renewal, and see exactly where (or whether) the warning shows. If it isn’t clear, ask Blackbaud support directly whether a constituent warning displays at the point of sale.
Things to avoid
- Marking the record inactive or deceased. Those statuses have real downstream effects on mailings, households, and reporting, and they misstate the facts.
- Typing “BANNED” into the name fields. It shows up on receipts, membership cards, and email greetings.
- Deleting the record. You lose the history you need if the ban is ever questioned, and the person can simply be re-added as a new constituent without any flag.
Closing the gaps a flag won’t cover
A flag only helps when the person is matched to their record. Several common paths sell admission without that match:
- Anonymous daily sales. Walk-up tickets are often sold without looking up a constituent at all. For high-risk cases, a short, access-controlled list at the desk with a manager contact is more reliable than any data flag.
- Online purchases. Web sales may create or match a constituent based on email and name. Someone with a new email address can end up as a fresh record.
- Duplicates. If the person already has two or three records, flag every one of them. Search by name, address, and phone before you assume you found the only one.
- Households and family memberships. Banning one adult doesn’t automatically say anything about the rest of the household. Decide whether the household’s membership card still admits other members, and make sure the flag is on the individual, not the household, unless the ban really covers everyone.
- Marketing. Exclude flagged constituents from appeal, renewal, and event-invitation lists. Use your communication preferences or solicit codes, or add an exclusion to the queries behind your mailings, so you don’t invite someone back by accident.
Keep it maintained
Build a saved query of everyone with an active restriction attribute, including the start and end dates and the approver. Review it with management on a set schedule, maybe quarterly. Expire the flags that have run their course, and confirm the ones that should continue. A short list that’s kept current is far more useful than a pile of stale flags nobody trusts.
Finally, train for the moment itself. Staff should know that seeing a flag means “call a manager,” not “confront the guest.” The data only gets the right person to the desk; how the conversation goes is up to your people.
Quick answers
Does Altru have a built-in “banned” status?
Not as a dedicated field that we know of. Most organizations combine an attribute for the structured flag with a note for the details, then confirm in a sandbox how warnings display during sales.
Should a banned member get a refund?
That’s a policy and legal decision for leadership. Record whatever is decided on the membership and in the note so the next staff member sees the full picture.
