Altru holds your members’ home addresses, giving history, payment activity, and sometimes notes about family situations or major gift conversations. It also gets touched by a lot of people: membership staff, development, the front desk, seasonal admissions workers, finance, and sometimes volunteers. Without written rules, each of those groups invents its own way of entering a constituent, coding a gift, or handling a refund, and the database slowly drifts into something nobody fully trusts.
A good Altru policy and procedures manual fixes that. It doesn’t need to be long. It needs to be specific to your organization, owned by someone, and actually used when people are trained. Below is how to put one together, plus what belongs in a confidentiality agreement for anyone with database access.
Separate policies from procedures
These are two different documents, or at least two clearly different sections, and mixing them is why many manuals become unreadable.
- Policies say what the rule is and why. “Every new constituent must be searched for before being added.” “Refunds over a set amount need a manager’s approval.” “Constituent data is never exported to a personal device.” Policies change rarely and are approved by leadership.
- Procedures say how to follow the rule in Altru, step by step, for a specific role. These change whenever your setup changes, and the database administrator should be able to update them without a committee meeting.
Keeping them apart means a new hire can read the policies in ten minutes and then go straight to the procedures for their own job.
What the policy section should cover
Data ownership and stewardship
Name one person (or a small group) as the owner of the database. That person approves new codes, attributes, membership levels, and queries that others depend on. Without a named owner, code tables fill with near-duplicates and nobody feels responsible for removing them.
Data entry standards
This is the part people consult most. Decide and write down:
- How names, salutations, and addresses are formatted, and which postal standard you follow.
- How households are created and when two people should be linked.
- The rule for searching before adding a new constituent, especially at point of sale.
- What goes in notes versus attributes versus interactions, and what never goes in notes at all (medical details, opinions about a donor, anything you wouldn’t want the constituent to read).
- Who may merge duplicate records, and how.
Access and security
Describe which roles get which level of access in Altru, and the principle behind it: people get what they need for their job and nothing more. Admissions staff selling tickets usually don’t need to see giving history. Spell out who approves new user accounts, how quickly accounts are disabled when someone leaves, and whether shared logins are allowed (they shouldn’t be). Review user access on a schedule, such as every quarter and at the end of each seasonal hiring cycle.
If you’re not sure how granular Altru’s role permissions can be for a particular area, test it with a dummy user in a sandbox or ask Blackbaud support before writing the policy around it. A policy that promises restrictions the software can’t enforce is worse than none.
Exports and reporting
Queries and exports are where data most often leaves the building. State who can export constituent lists, where exported files may be stored, how long they’re kept, and how they’re deleted. Include third-party vendors here too: mailing houses, email platforms, and survey tools all receive your data.
Financial controls
Cover refunds, voids, discounts, comps, and adjustments to posted revenue. Note who reconciles daily sales and batches with finance and how often. These rules usually already exist somewhere in finance; the manual should point to them and explain how they apply inside Altru.
What the procedures section should cover
Organize procedures by role, not by Altru feature. A front desk associate doesn’t care how the membership program is configured; they care how to sell a membership, look up a member, and handle a return. Typical sections:
- Front desk and admissions: daily sales, advance sales pickup, membership lookups, end-of-day close.
- Membership: new joins, renewals, upgrades, lapsed members, card replacement.
- Development: gift entry, acknowledgments, pledges, tributes, recurring gifts.
- Group sales and events: booking, deposits, changes, cancellations.
- Database administration: duplicate review, code table cleanup, user setup, routine queries.
Write each procedure from your own screens. Have someone who does the job walk through it while you take notes, then have a new person follow the written version and mark every spot where they got stuck. Screenshots help, but they go stale after updates, so date them.
The confidentiality agreement
Anyone who can see constituent data, including volunteers and temporary staff, should sign a short confidentiality agreement before receiving a login. Keep it readable; a one-page agreement people understand is better than three pages they skim. It typically covers:
- What counts as confidential: personal contact details, giving and membership history, payment information, and internal notes.
- That access is for job duties only. Looking up a neighbor, a celebrity, or a board member out of curiosity is a violation.
- No sharing of passwords, no copying data to personal email, phones, or cloud storage.
- That the obligation continues after the person leaves the organization.
- How to report a suspected breach or mistake, and that reporting quickly is expected and won’t be punished.
- Consequences for violations.
Have your HR lead or legal counsel review the final wording, especially if you operate in a state with specific privacy rules or handle data from international visitors. Store signed copies with HR records and note the signature date somewhere the database administrator can check before creating an account.
Keeping the manual alive
The common failure isn’t a bad manual; it’s an abandoned one. A few habits help:
- Put an owner and a “last reviewed” date at the top of every section.
- Review the whole thing once a year, and the relevant procedures whenever you change membership levels, pricing, or workflows.
- Make it part of onboarding. New users read the policies, sign the confidentiality agreement, and train from the procedures, in that order.
- Keep it somewhere easy to search, like a shared drive or intranet page, not a binder in the database administrator’s office.
- When a data problem turns up, ask whether the manual covered it. If not, add a line.
Quick answers
Does Blackbaud provide a template?
Blackbaud publishes general documentation and training on using Altru, but your policies depend on your own codes, programs, and staffing. Treat any outside template as a checklist and rewrite it in your own terms.
Should volunteers sign the same agreement as staff?
Yes, if they have any access to constituent data. Many organizations also give volunteers a more limited role in Altru than paid staff.
How long should the manual be?
Policies can fit in a few pages. Procedures will grow over time, which is fine as long as each one is short and organized by role.
