Guide to Adding Users and Managing Permissions on SETS Platform

Adding users and managing permissions in SETS

SETS uses role-based access, so each user can only do what their permissions allow. New users can be created by an Account Administrator or Account Security Administrator, while the guidance says changes to existing user details and permissions are for the Account Administrator. Access should be limited to the tasks a user actually needs to perform, and the Portal dashboard viewer role must be enabled or the user cannot access SETS at all.

• Only authorised administrators can manage user access; if the Create or update users link is missing, the logged-in person does not have that function.
• When creating a user, the administrator must enter an email address, username and password, then assign the relevant permissions.
• On first login, the new user must change their password, log in again with the new password and accept the Terms and Conditions.
• Permissions are separate by function, including creating or updating draft returns, submitting returns, amending returns, making claims and sending secure messages.
• The Portal dashboard viewer role is essential because a user cannot access the system without it, even if they have other roles.
• The guidance contains some ambiguity over whether both administrator roles can change permissions for existing users, so organisations should apply clear internal controls.

Scroll down for the full analysis.

How to add users and manage permissions in SETS

This page explains how user accounts are managed in SETS and why permissions matter. In practice, the person who controls user access decides who can log in, who can prepare returns, who can submit them, and who can carry out later actions such as amendments, claims, and secure messages.

What this rule is about

SETS uses role-based access. A user can only do what their assigned permissions allow. This means two separate questions matter:

• who is allowed to create or change user accounts
• what roles each user is given once the account exists

The source material also makes clear that access to the system itself depends on one particular role: dashboard viewing. Without that role, a user cannot access the system.

What the official source says

The official material says that only certain administrative users can add new users in SETS. New users may be added by the Account Administrator or the Account Security Administrator.

To add a user, the administrator signs into SETS, goes to Account details, then uses the Create or update users function. If that link is not visible, the person logged in does not have the necessary administrator functionality.

When creating a user, the administrator must enter:

• email address
• username
• password

The administrator must also assign permissions. Those permissions determine what the user can do in SETS.

After the account is created, the new user should be told their username and password. On first login, the user will be required to change their password, log in again using the new password, and accept the Terms and Conditions.

The source then distinguishes between adding users and changing existing users. It says only the Account Administrator can change user details and permissions. The user details that can be changed are:

• name
• email address
• password

All users can change their own password, and the source says this should be done immediately if there is any concern that the account may have been compromised.

For permissions, the source lists the following user roles:

• Create draft returns: allows the user to create a draft return
• Update draft returns: allows the user to update a draft return
• Submit returns: allows the user to submit a return
• Portal return amendment user: allows the user to amend a return up to 12 months after the filing date
• Portal messenger user: allows the user to create and send secure messages
• Portal claim user: allows the user to make a claim against a filed return more than 12 months after the filing date
• Portal dashboard viewer: allows the user to view the dashboard, and this role must be enabled for the user to access the system

What this means in practice

The practical point is that SETS does not give all users the same powers. Access needs to be set deliberately.

If a person only prepares draft returns, they do not necessarily need permission to submit them. If a person deals with post-filing corrections within 12 months, they may need the amendment role. If they handle later claims, they may need the claim role instead. If they need to use secure messaging, that permission must also be turned on.

The dashboard viewer role is especially important. The source says this role must be enabled for a user to access the system at all. So a user may appear to have substantive roles, but still be unable to get into SETS if dashboard access has not been granted.

The source also suggests a control structure within the organisation. Administrative authority is limited. If a user cannot see the Create or update users link, they cannot manage accounts and must contact the person in the organisation who is responsible for SETS user administration.

How to analyse it

When deciding what access a person should have, it helps to work through the issue in stages.

• First, identify whether the person needs to be added as a new user or whether an existing account just needs updating.
• Second, check who in the organisation has the authority to make that change. The source says new users can be added by the Account Administrator or Account Security Administrator, but changes to user details and permissions are stated to be for the Account Administrator.
• Third, decide what the user actually needs to do in SETS. Drafting, updating, submitting, messaging, amending, and making claims are separate functions.
• Fourth, make sure the dashboard viewer role is enabled. Without it, the user cannot access the system.
• Fifth, after setup, make sure the new user completes the first-login steps: password change, fresh login, and acceptance of the Terms and Conditions.

A sensible internal check is to compare each role against the user’s actual job. Over-permissioning can create control risks. Under-permissioning can stop work from being done.

Example

A firm wants to give a junior team member access to prepare returns but not file them. The administrator creates a new user with an email address, username, and temporary password. The administrator gives that user the Create draft returns role, the Update draft returns role, and the Portal dashboard viewer role. The administrator does not give the Submit returns role. The user can then log in, access SETS, and prepare or edit drafts, but cannot submit a return.

Why this can be difficult in practice

The source material contains a point that may need careful handling internally. It says that permissions are assigned or changed by either the Account Administrator or Account Security Administrator, but it also says only the Account Administrator can change user details and permissions. Read literally, those statements are not perfectly aligned.

In practice, organisations should be careful to distinguish between:

• creating a new user
• changing personal details such as name or email address
• changing permissions for an existing user

The source clearly allows both administrator roles to add new users. It is less clear, on the face of the page, whether both roles can change permissions for existing users in every case, because one part of the page reserves that function to the Account Administrator alone. That is an operational ambiguity in the guidance rather than a tax-law issue, but it matters for access control.

Another practical difficulty is that users may assume that being given a specialist role automatically gives system access. The source says that is not enough: dashboard viewer must also be enabled.

Key takeaways

• Only authorised administrative users can create SETS users, and the source gives a central role to the Account Administrator.
• User permissions are function-specific, so access should be matched to what the person actually needs to do.
• The Portal dashboard viewer role is essential because, according to the source, it must be enabled for the user to access the system.

This page was last updated on 24 March 2026

Useful article? You may find it helpful to read the original guidance here: Guide to Adding Users and Managing Permissions on SETS Platform

View all LBTT Guidance Pages Here