Someone renamed a membership level last Tuesday. Now the renewal web form shows the wrong benefit text, a query that fed the board report returns zero rows, and nobody remembers touching anything. Questions like “who changed this, and when?” come up in every Altru database with more than one administrator, and the honest answer is that Altru gives you only part of what you need to answer them.
This guide covers what you can realistically see in Altru today, where the gaps are, and the habits that fill those gaps so configuration changes stop being a mystery.
What Altru can and can’t tell you
Altru tracks a lot of who-did-what at the record level. Many constituent, revenue, and membership records carry date-added and date-changed information, and some query views expose fields for the date a record was changed and the user who changed it. That’s useful for transactional data: a gift that was edited, an address that was updated, a membership whose expiration moved.
Configuration is a different story. Changes to things like attribute categories, code tables, price lists, membership programs, web forms, and security roles are where administrators most want an audit trail, and that’s where visibility is thinnest. We aren’t aware of a single built-in log in Altru that lists every administrative change with a before-and-after value, and we haven’t seen a native way to alert an administrator when someone edits a table, attribute, or web form.
Because Altru’s capabilities vary by release and by what your organization has enabled, don’t take our word, or anyone’s, as final. Two ways to confirm for your own database:
- Open a ticket with Blackbaud support and ask specifically which areas keep change history and whether any of it is reportable.
- In a test or sandbox environment, edit a code table entry and an attribute, then look for those changes in query. If you can’t find them there, assume you can’t find them in production either.
Use query for the parts Altru does record
Where change information exists, query is the way to get at it. Browse the views you care about most (constituents, revenue, memberships) and look for fields along the lines of date changed and changed by. If they’re there, build a small set of saved queries:
- Records changed in the last 7 days, grouped by user. This is a quick check for unexpected bulk edits, such as an import that touched far more records than planned.
- Revenue changed after its batch was committed. Edits to posted revenue usually deserve a second look from finance.
- Memberships whose dates changed recently. Hand-edited expiration dates are a common source of member complaints and benefit disputes.
Put these on a calendar reminder for whoever owns data quality. A query nobody runs is not an audit.
Keep your own change log for configuration
For the configuration side, the dependable answer is a human one: a shared log that every administrator updates whenever they change setup. A spreadsheet or a shared document is enough. Each entry needs:
- Date and the person making the change
- Area (for example, membership program, price list, web form, attribute, security role)
- What it was before and what it is now
- Why, and who asked for it
- What else might be affected: queries, smart fields, reports, web forms, email templates
That last column is the one that saves you. Most “mystery” breakages in Altru are downstream effects: a renamed attribute breaks a query filter, a retired code table value drops records out of a report, a changed price type shifts what a web form displays.
Take before-and-after snapshots
Before editing anything substantial, record the current state. Screenshot the setup screen, or export the relevant list if Altru lets you. It takes a minute and gives you something to restore from if a change goes wrong, since configuration changes don’t come with an undo button.
Reduce how many people can make changes
The simplest way to audit admin changes is to have fewer people making them. Review your security setup with these questions in mind:
- Who actually has system administrator rights? Former staff, consultants, and shared logins should not be on that list.
- Can you give department leads narrower roles that let them do their daily work without access to configuration areas?
- Does everyone sign in as themselves? Shared accounts make any changed-by field meaningless.
Schedule this review at least twice a year and whenever someone leaves the organization.
Put a light approval step in front of risky changes
Not every edit needs sign-off, but some areas affect revenue or the public website directly. A reasonable rule is that changes to membership programs, price lists, web forms, and security roles get a quick heads-up to one other administrator before they happen, and an entry in the log after. For larger changes, try them in a sandbox first if you have one.
Replacing notifications you don’t have
Without built-in alerts, aim for detection that’s fast enough. A weekly routine works well for most organizations:
- Run the changed-records queries and scan for anything surprising.
- Load each public web form and check prices, descriptions, and confirmation text.
- Run your most important recurring reports and compare totals against the prior week.
- Read the change log and confirm each entry matches what you see.
It isn’t automatic, but it means a broken form or report gets caught within days instead of at month-end close.
Quick answers
Can I see who edited a specific constituent record?
Often yes, if the relevant query view exposes changed-by and date-changed fields. Check in query; if those fields aren’t available, ask Blackbaud support what history is kept for that record type.
Can Altru email me when someone changes a web form or attribute?
We don’t know of a native setting that does this. Confirm with Blackbaud support, and in the meantime rely on a shared change log and a weekly review.
