A new volunteer coordinator says she can’t find the group sales calendar. A seasonal cashier gets an error when he tries to refund a ticket. As the Altru administrator, you want to see exactly what they see, but you’re logged in with full rights, so everything looks fine from your chair.
The short answer: as far as we know, Altru has no built-in “view as this user” or impersonation mode that lets an administrator switch into someone else’s session without logging out. Permissions come from the security roles assigned to each application user, and you see the system through your own roles. If you’re not sure whether something like this exists in your environment, ask Blackbaud support before you build a workaround. For most teams, though, a couple of simple habits get you close enough.
Why you can’t just borrow their view
Each person who signs in to Altru is an application user tied to their own login. What they can open, edit, or run is decided by the roles assigned to that user, plus any site or record-level restrictions your organization uses. Two consequences follow:
- Your admin view hides the problem. Administrators usually have access to everything, so a missing menu, a blocked task, or a query that won’t open simply doesn’t happen to you.
- Logging in as them isn’t the answer. Asking staff for their password breaks basic security practice and muddies your audit trail, because anything you change shows up under their name. Don’t do it, even for a quick check.
Option 1: Keep a test user for each role
The most reliable approach is to create a small set of test users, one for each role your staff actually use: front desk, membership, development, group sales, read-only finance, and so on. Give each test user exactly the same roles as the real staff member, and nothing else.
When someone reports “I can’t see X,” sign in as the matching test user and look. You’ll see the same menus and hit the same permission errors, without touching anyone’s real account.
A few things to check before you set this up:
- Licensing. Test users may count toward your user total. Confirm with Blackbaud how your contract handles extra application users before creating several.
- Login method. Each test user needs its own sign-in identity, usually a separate email address. A shared mailbox or plus-addressing on your domain is often the easiest way, but confirm your organization’s login setup accepts it.
- Naming. Name them clearly (for example, “TEST – Front Desk”) so nobody mistakes them for real people in reports or audit history.
- Keep them in sync. When you change a role, the test user picks up the change automatically because it holds the same role. If you assign extra one-off permissions to individual staff, the test user won’t reflect those, so note them.
Option 2: Use a second browser profile so you don’t log out
The annoying part of testing is signing out of your admin account and back in. You can avoid that by keeping the test login in a separate browser or browser profile. Stay signed in as yourself in your normal window, and open the test user in a different browser, a separate profile, or a private window. Each one keeps its own session, so you can compare the two views side by side.
If your browser shares sign-in cookies between windows, a fully separate browser is the cleanest fix. Some single sign-on setups remember the last account you used, so watch which identity you pick at the login screen.
Option 3: Read the role, not the screen
Sometimes you don’t need to see the screen at all. Look at the user’s record in the security area of Altru, note which roles they hold, then open those roles and review what they grant. This answers questions like “Can our cashiers issue refunds?” or “Why can’t development staff edit membership programs?” without any second login.
It’s slower for visual issues, such as a page section that doesn’t appear, and it won’t catch problems caused by site restrictions or record-level settings. Use it alongside a test user, not instead of one.
Option 4: Watch over their shoulder
For one-off problems, the fastest route is often a screen share. Ask the staff member to reproduce the issue while you watch, and write down the exact steps and any error text. You see their real view, with their real roles, and nobody shares a password.
A simple routine for permission troubleshooting
- Get the exact steps and the exact error message from the staff member.
- Check which roles that person holds.
- Reproduce it as the matching test user in a separate browser.
- Adjust the role, or create a narrower role if the change shouldn’t apply to everyone who holds the current one.
- Retest as the test user, then ask the staff member to confirm.
- Note what changed and why, so the next admin understands the role history.
One caution: role changes affect everyone who holds that role. Before you add a permission to fix one person’s issue, check who else holds the role and whether they should get the same access.
Quick answers
Can an Altru admin see another user’s screen without logging out?
Not through a built-in impersonation feature that we’re aware of. A test user with matching roles, opened in a separate browser, is the practical substitute. Blackbaud support can confirm whether anything has changed in your version.
Is it okay to log in with a staff member’s credentials to troubleshoot?
No. It weakens security and makes your changes look like theirs in the record history. Use a test account or a screen share instead.
