You search for a member, click their name, and the screen just sits there. Ten seconds. Fifteen. Meanwhile someone is standing at the counter waiting to renew. Slow constituent records are one of the most common complaints Altru admins hear from staff, and also one of the hardest to pin down, because the cause is often not where people first look.
Altru is a hosted application, so you can’t tune its servers or its database. What you can do is work out which kind of slow you’re dealing with, fix the parts that live on your side, and hand Blackbaud a report specific enough to act on.
First, figure out what kind of slow it is
Before changing anything, answer four questions. The answers point to very different causes.
- Is it every record, or certain ones? If one long-time donor takes forever and a brand-new constituent opens instantly, the record itself is the likely factor. If everything is slow, look at the environment.
- Is it every user, or one person? One slow workstation usually means a browser, device, or network issue at that desk.
- Is it the whole record, or one tab? If the record opens but a particular tab (revenue history, for example) drags, that narrows things considerably.
- Is it certain times of day? Slowness that comes and goes can line up with your own heavy activity, or with something on Blackbaud’s side.
Write the answers down with a few example lookup IDs and times. You’ll need them later either way.
When specific records are the problem
A constituent record isn’t one row of data. When it opens, Altru pulls together contact details, relationships, household information, memberships, revenue, interactions, attributes, notes, and summary information. Records with years of history simply have more to assemble. Common culprits:
- Very long revenue history. Frequent visitors who buy tickets every week, or donors with recurring gifts going back many years, can carry thousands of transactions.
- Large households and relationship webs. Organization records with many linked contacts, or households that have been merged together repeatedly, add work to every load.
- Catch-all records. Many organizations have a generic “walk-up” or “anonymous guest” constituent that daily sales get attached to. Over time that record collects an enormous amount of activity, and it’s often the slowest record in the database.
- Piles of notes, attributes, or attachments. Rarely the main cause on their own, but they add up on records that are already heavy.
You generally can’t make a legitimate history smaller, and you shouldn’t delete real transactions to speed up a screen. But you can stop the problem from growing. If daily sales are piling onto a single placeholder constituent, consider whether that’s still the right practice, and ask Blackbaud support whether a fresh placeholder record (with the old one kept for history) would help. Test that kind of change in a sandbox or with support guidance before doing it in production.
Duplicates matter here too, though indirectly. When the same person exists three times, staff often open all three looking for the right one, and merges done later can stack a lot of history onto a single surviving record. Keeping duplicates under control keeps both of those problems smaller.
When one person or one computer is the problem
This is the easiest case to fix, and it’s worth ruling out before you open a support case.
- Try another supported browser on the same machine. If the record loads fine there, the original browser is the issue. Check Blackbaud’s current list of supported browsers rather than assuming.
- Clear the cache and try a private window. A private window also disables most extensions, which is a quick way to test them.
- Look at extensions. Ad blockers, password managers, and security extensions sometimes interfere with web applications. Disable them one at a time.
- Check the network path. VPNs, guest Wi-Fi, and content filters at the front desk can all add delay. Compare the same record on a wired office connection.
- Consider the hardware. Older point-of-sale terminals with many tabs open can struggle with any modern web application, Altru included.
When everyone is slow at once
If all users see slowness across all records, the cause is most likely outside your building. Check Blackbaud’s system status page first. If nothing is posted, open a support case.
It’s also worth noticing whether slowdowns line up with heavy work your own team runs, such as large exports, big queries, or long-running processes started during open hours. Whether that work affects other users’ screen loads in a hosted environment isn’t something you can confirm from the outside, so ask support directly. If they say it can, move that work to early morning or after close.
Giving Blackbaud something they can act on
“Altru is slow” tends to get a slow answer. A useful support case includes:
- Lookup IDs of two or three slow records, plus one that loads normally for comparison
- Dates and times you saw the slowness, with your time zone
- Which users and browsers were affected, and whether a different browser or network changed anything
- Whether the whole record or a specific tab is slow
- Roughly how long it takes to load
That lets support reproduce the problem against specific records instead of guessing, and it shows you’ve already ruled out the local causes they’d otherwise ask about first.
Keeping it from coming back
Once you’ve found the cause, make it part of routine database hygiene: watch for catch-all records that keep growing, keep duplicates under control, and check new front-desk hardware and browser updates against Blackbaud’s supported list before they go live. Slow records seldom have one dramatic cause. Most of the time it’s a few ordinary habits adding up, and those you can change.
