Support Access

When you open a support ticket that needs Atlas Systems to look at your system directly, Support Access is how that happens. There is no shared support login and no password held by Atlas Systems. Each sign-in is tied to a named person, runs under a role you choose, lasts only while you allow it, and leaves a permanent record on your own system.

Support Access starts turned off. Nothing on this page takes effect until you enable the grant and save.

Open it at Customization Manager > Roles & Permissions > Support Access. The page is gated by the Roles & Permissions configuration capability, the same one that governs role administration — see Permissions Overview. API keys cannot reach it at all, whatever their scope, because a key able to enable the grant or repoint it could open a sign-in path. The page has two tabs: Settings, where you set the grant, and Activity, where you review what has been done.

The normal path

1. Confirm the Registration ID is filled in on the Settings tab.
2. Choose the role support sessions run under.
3. Set a site scope and an expiry if you want them.
4. Leave the capability switches off unless you have been asked for one.
5. Turn on Support access enabled and click Save.
6. Turn the grant back off when the ticket is closed.

How a support sign-in works

You do nothing at the moment of a sign-in. Once the grant is on, each connection runs like this.

1. The sign-in starts at Atlas Systems. The person signing in uses their own Atlas Systems account with multi-factor authentication, selects your Aeon server, and enters a reason and a ticket number.
2. Your server checks the grant. The grant must be configured, enabled, unexpired, and pointed at a role that still exists. On a multi-site system, the site scope must resolve to at least one site. A failure on any of these refuses the sign-in and records why.
3. A per-person account is used. On a first connection, Aeon creates a staff account with the sign-in method Atlas Support. It has no password and no authenticator. Later connections reuse the same account.
4. Your role and scope are applied fresh. The account takes the role and site scope from the grant at every sign-in, so changing the grant changes what the next sign-in receives.
5. Work happens in the staff web client, under that role, minus everything in What Atlas Systems support can never do and anything you have not switched on.
6. You get an email, if you asked for one. A notification address receives a message naming who signed in, the reason, and the ticket.
7. The session ends on sign-out, after 20 minutes idle, at an 8-hour cap, or immediately when you disable the grant. A permanent digest then appears on the Activity tab.

The idle window is a server setting

Twenty minutes is the default, not a fixed limit. It is set on the server with the configuration key SupportAccess:IdleTimeoutMinutes, and a value of zero or less turns the idle rule off entirely, leaving only the 8-hour cap. There is no control for it in the Customization Manager, so changing it means a change on the server. An unreadable value falls back to 20 minutes rather than failing sign-ins.

note

If one of your own staff already has Aeon open in the same browser, Aeon asks before switching. It never replaces a signed-in user silently.

Enabling Support Access

1. Open Customization Manager > Roles & Permissions > Support Access. The Settings tab opens first.
2. Check the Registration ID in the Registration card. Atlas Systems issues it when your site is registered with the support system, normally during provisioning. If the page shows a notice that the site has no registration ID yet, contact Atlas Systems support before going further — the grant cannot be enabled without one.
3. In the Grant card, choose the Role support sessions run under. The picker starts on No role selected, and a role is required.
4. If your site has site groups, choose the Site scope. The control is hidden when you have none.
5. Set Expires. Until revoked is on by default. Switching it off shows a date picker that starts 30 days ahead.
6. Optionally fill in Notify on each support sign-in.
7. Review the capability switches and the privacy field group. Most sites leave every switch off and keep the default group.
8. Turn on Support access enabled and click Save.

The header shows an Enabled or Disabled badge, so you can confirm the state at a glance. Discard returns the form to the last saved values.

warning

Aeon refuses to save an enabled grant without both a role and a registration ID, and it refuses an expiry date in the past. If another administrator saves the page while you are editing it, Aeon reloads the current settings and asks you to reapply your change.

The Grant settings

Setting	What it does
Support access enabled	The master switch. While off, no support sign-in is accepted. Turning it off ends any session running at that moment.
Role support sessions run under	Any role from your own list. The session gets exactly that role's permissions and field restrictions, so you can grant a full administrator role, a narrow one, or the role a staff member is having trouble with. Aeon refuses to delete a role while the grant points at it.
Site scope	Appears only when you have site groups of your own. All sites lets a session move between all of your sites like fully assigned staff. A site group limits the session to that group. If the chosen group later ends up with no sites in it, sign-ins are refused — see the warning below.
Expires	Until revoked keeps the grant open until you turn it off. Switching it off lets you pick a date. There is no maximum.
Notify on each support sign-in	An address that receives an email on every sign-in, naming who, why, and the ticket. Leave it blank for no email. Sign-ins are recorded either way.

Changing the role, site scope, or expiry of an enabled grant ends any live session, so the change applies at once rather than at the next sign-in. Changing the notification address does not end sessions.

An empty site group silently blocks support sign-ins

If the grant points at a site group and every site is later removed from that group, Aeon refuses support sign-ins rather than treating the empty scope as "all sites". Nothing warns you in advance: the Settings tab still shows the grant as enabled, and the refusal appears only in the audit log. If Atlas Systems support reports that it cannot connect while the grant looks correct, check that the site group still has sites in it.

What Atlas Systems support may do

The card headed What Atlas support may do holds five switches. All five are off by default and stay off until you turn them on. Most sites enable one only during implementation or on a test system, then turn it off again. The switches apply to a running session at its next action.

Switch	What it allows when on
Set up and manage staff accounts	Create staff accounts, edit staff, assign roles and sites, and run bulk staff operations. Accounts created this way never get a password — the new person sets their own through an emailed link. This switch never applies to Atlas Support accounts themselves, and never allows changing anyone's sign-in method or email address.
Edit roles and permission structure	Create and change roles and field groups. Because the granted role is the ceiling on what a session can do, editing roles could raise that ceiling, which is why it is a separate choice. The privacy field group stays locked either way.
Edit single sign-on configuration	Change SSO settings and apply them. The SSO screens can always be viewed for troubleshooting; this switch controls editing.
Edit email routing and delivery	Change SMTP settings, the staff web URL, and the addresses email templates send to. While this is on, email sign-in links could be redirected, so most sites enable it only during setup. Editing template content does not need this switch.
Install and manage server add-ons	Server add-ons run on your Aeon server, so this allows code to be installed and run there. Browser add-ons are unaffected — they run sandboxed in the browser and are ordinary support work.

warning

With both Set up and manage staff accounts and Edit email routing and delivery on, an account could be created and the destination of its setup link controlled at the same time. Aeon shows a warning when both are on. Grant the pair only while actively working a ticket, then check Accounts created by Atlas on the Activity tab.

What Atlas Systems support can see

The Privacy field group hides fields from support sessions on top of whatever the chosen role already restricts. It applies everywhere data appears — grids, detail views, search, and exports. Your own staff on the same role are unaffected.

Aeon includes a field group named Atlas Support Privacy and selects it by default. It hides 21 patron fields: last name, email address, phone, fax, both the primary and shipping address blocks, both ID and alternate ID with their types, and date of birth. First name and username stay visible on purpose, so a support conversation can still refer to a specific person or request.

• To hide more or fewer fields, edit the group on the Field Groups page, or pick a different group here. See Field Restriction Groups and Editing a Field Restriction Group.
• Atlas Support Privacy is marked as a system default, so it cannot be deleted while the grant points at it.
• Choosing None — support sees whatever the role sees removes the extra restrictions. That is a deliberate choice and never the default.
• A support session can never edit the selected group or change this setting, even with roles editing switched on.

Registration

The Registration card shows two values. Neither is something your staff normally manage.

Registration ID is issued by Atlas Systems when your site is registered with the support system. Your server accepts sign-ins addressed to this ID only. While it is blank, the grant cannot be enabled. Do not change it unless Atlas Systems support asks you to.

Trusts broker is the address of the Atlas Systems sign-in service your build accepts sign-ins from. It is compiled into Aeon and shown for reference only — it is not an input, so there is nothing here for a site to misconfigure.

Your server must reach that address over HTTPS to verify a sign-in. If outbound web traffic is blocked, allow https://supportaccess.atlas-sys.com.

What Atlas Systems support can never do

These actions are refused whatever role you grant, including a full administrator role, and whatever the capability switches say. Each refusal is recorded and counted as blocked on the session record.

• Reset anyone's password or multi-factor authentication.
• Send or revoke SSO invitations, or convert an account between sign-in methods.
• Copy a staff account, because copying sets a password known to the copier.
• Create, change, rotate, or delete API keys or API key templates.
• Edit this Support Access settings page. It can be read, so a session can see what it has been allowed.
• Create, edit, or delete site groups, or change their membership.
• Read or write the customization tables holding the Web Platform API key and patron validation credentials.
• Change the logging settings that produce the session records below.
• Upload or reset Implementation module specifications.
• Edit or delete the privacy field group the grant points at, or change any Atlas Support account.

Reviewing support activity

The Activity tab is your permanent record of what has been done on your system. Aeon writes it, and no one can edit it, including Atlas Systems. It is kept after ordinary log entries are pruned.

Support sessions

One entry per sign-in, newest first, 25 to a page. Each row names the person who connected, the time window and duration, and the reason and ticket given. A badge shows the state:

Badge	Meaning
Active now	The session is still running.
Signed out	Ended normally.
Expired	Ended on the idle timeout or the 8-hour cap.
Revoked	Ended because you disabled or changed the grant.

Counts on the right summarize how many records were viewed and changed, and how many actions were blocked.

Expand a row to read its digest — the actions taken, grouped by type, with the records touched and any blocked attempts. A live session has no digest yet; it is written when the session ends, and a link takes you to the activity log meanwhile. Export CSV downloads the whole session history, which is the artifact a security assessment usually asks for.

Accounts created by Atlas

This card appears once a support session has created at least one staff account. It lists each account with the email address its setup link went to. Check that every address belongs to your institution.

The audit log

The Log Viewer under Customization Manager > System > Logs has an Audit view. It shows every sign-in on the staff web client, including each accepted support sign-in, each refused one and the reason, each blocked action, and every change to the grant itself.

Atlas Support accounts in your staff list

People who have connected appear on your Staff page with an Atlas Support badge. These are real per-person accounts, but they behave differently from your own staff:

• They have no password and no authenticator, and cannot be given either. Password resets, authenticator resets, setup links, and SSO invitations are all refused. See Resetting a Staff Member's Password and Resetting a Staff Member's Authenticator for how this differs from an ordinary account.
• Their role and site assignments come from the grant and are reapplied at every sign-in. Editing them on the Staff page is refused — change the grant instead.
• They cannot be converted to another sign-in method or copied.
• You can lock, deactivate, or delete them. Each of those blocks that one person until you reverse it. Deleting is harmless, because the next permitted sign-in creates a fresh account.

warning

If an Atlas Support account is ever found holding a password or desktop Client Access, the Support Access page names it in a warning and refuses support sign-ins to it until that is fixed. Clear the Client Access checkbox in the staff editor. An account that has been given a password must be deleted — the next sign-in re-creates it clean.

Turning access off

Action	Effect
Turn off Support access enabled and save	Ends every live session at once and refuses new sign-ins. Records close as Revoked. The accounts stay in your staff list but cannot be used.
Set an expiry date	Access ends automatically. Nothing needs doing on the day.
Switch off a capability	Applies at the session's next action. A live session continues with narrower permissions.
Lock, deactivate, or delete one account	Blocks that one person. Others are unaffected.

Re-enabling later needs no help from Atlas Systems. The registration ID stays in place, so you turn the switch back on and save.

Common questions

Should we leave Support Access on all the time?

No. Leave it off and turn it on when a ticket needs it. Turning it back on is one switch and a Save. If you do leave it on through a stretch of active work, set an expiry so it closes itself, and set a notification address so every sign-in is visible.

Can Atlas Systems sign in without our knowing?

Not while the grant is off, expired, or missing a role. When it is on, every sign-in writes a permanent session record and an audit entry, and sends an email if you set an address. None of those can be altered or removed from the support side.

Which role should we choose?

The least that will do. For most tickets, a role that can view requests, users, and activities is enough. When the problem is that a staff member's screen looks wrong, choose that staff member's role so the session sees exactly what they see. Use an administrator role when configuration has to change, and consider an expiry when you do. See System Default Roles.

What is visible about our patrons?

Whatever the granted role allows, minus the privacy field group. With the default group that means no last names, contact details, identifiers, or dates of birth.

We use the Aeon desktop client too. Does this affect it?

No. Support Access covers the staff web client only. Atlas Support accounts never hold desktop Client Access, and Aeon refuses to grant it to them.