What each part of the extension needs

The extension shows a tab only when your instance has it switched on and the signed-in person's role allows it. It lets a person write to HaloPSA only when their login is linked to a HaloPSA agent. This page lists what each part needs, what the extension asks the browser for, and where its data goes. It is for administrators who assign roles and review the extension's permissions.

Before you start: roles are assigned in QuantumOps; see Inviting people, roles and agent links and Roles and access. The modules your organisation has are listed in Modules reference. The Switched on for this server card on the Browser Extension page shows which switches your instance has on.

Tabs, modules and roles

The table lists every part of the extension that depends on something. A part marked Always on has no switch of its own. A part marked Any signed-in user needs no particular role. The extension also hides a part when the server would refuse the person's role, so a listed tab is one the person can use, with two exceptions: Approvals, which everyone sees but only Administrators can act on, and Chat, which opens a card when chat is not switched on for your instance.

The Halo launcher tab is a HaloPSA custom tab, not a panel tab; see The QuantumOps launcher tab in HaloPSA.

Roles come from your sign-in service and travel in the person's sign-in token. A role you add or remove applies once that sign-in renews, which the extension does in the background, and at the latest at the person's next sign-in. The panel works out which tabs to list each time it opens or signs in. See Team Management.

In the web app, the Dispatch Board entry in the sidebar shows while your organisation's Call Center Operations module is on; see Opening the dispatch board.

Two levels of trust

The panel treats a signed-in person in one of two ways.

• Signed in. A person with a QuantumOps login in your organisation can read what the panel shows and give feedback, such as rejecting a suggestion as not useful.
• Linked to a HaloPSA agent. A person whose login is linked to a HaloPSA agent can also do everything that writes to HaloPSA or sends something on their behalf. Examples are Approve on a suggestion, Post to Halo, dispatching from the Triage tab, posting a Q-Notice, Regenerate on the Client tab, and nudges and replies from the dispatch board. The change appears in HaloPSA under the person's own agent.

Without the link the panel stays read-only: the buttons that would write are greyed out, and a Read-only chip says why.

The link is made in one of two ways:

1. By e-mail address. QuantumOps matches the e-mail address the person signed in with to an agent's e-mail address in HaloPSA. The sign-in service must have verified the address; an unverified address never matches.
2. By hand. An administrator uses Link a HaloPSA agent in Team Management. A link made by hand wins over e-mail matching from then on.

Team Management counts people under Fully Linked, Agent Only and Login only, and marks each person Linked, Agent only or Login only. A login that has no agent can use the extension, read-only.

These are not the Tier badges of the dashboards embedded in HaloPSA; see Trust levels of embedded tabs in the Glossary.

Browser permissions

The browser asks for these when the extension is installed, or grants them without asking when your administrator installs the extension by policy:

The browser asks for these only at the moment they are needed:

• A custom HaloPSA domain. The browser asks for that exact domain when a person allows it from the panel's prompt or adds it under Halo URLs in Options.
• A privately hosted QuantumOps address. The browser asks when a person selects Use this URL for an address outside the standard QuantumOps domains.
• The microphone. The browser asks once, from the microphone check in the Call tab, when the person selects Allow microphone. The check records nothing.
• Notifications. If a person turns on Browser notifications in the dispatch board's settings, the browser asks for permission to show them.

The extension never asks for your list of open tabs, your cookies, your web traffic or access to every site.

The browser's install warning says the extension can read and change data on the HaloPSA and QuantumOps sites it lists. Change is the browser's general wording for an extension that runs a script on a page. This extension reads only the address of a HaloPSA page and does not change the page.

Where the data goes

• The extension sends data only to your own QuantumOps instance. It has no analytics and sends nothing to a third party.
• The Firefox build declares that it collects authentication information, personally identifying information and website activity, and Firefox shows this when you install it. In practice that is the sign-in token, the person's name and e-mail address, and the record numbers read from HaloPSA addresses, all sent only to your QuantumOps instance.
• From HaloPSA addresses it reads only the ticket, client, user or agent number. It does not read the page, its content or its cookies.
• The sign-in token lives in memory and is gone when the browser closes.
• Every write to HaloPSA goes through QuantumOps's connection to HaloPSA, as the person's own agent, after the person confirms it.

When a person revokes access in Firefox

Firefox lets a person take back the extension's access to a site in the browser's own settings. The extension checks its registrations when the browser starts and whenever its list of domains changes, and it stops following a site it no longer has access to. Re-check permissions in Options, under Diagnostics, runs the same check on demand. To restore access, allow the site again from the panel's prompt or under Halo URLs in Options.

Next steps

• Rolling out the extension to technicians: install it on managed devices.
• Finding your way around the side panel: what each tab looks like.
• Troubleshooting the extension: when a tab is missing.