Solution
In SystemLink, a user's permissions are dependent on:
- The Role
- The Workspace
- The sign in technology
Each of these factors needs to be carefully assessed to ensure that required settings are not missing, and to verify that the underlying problem does not relate to the sign in technology.
Work through the steps below to resolve this issue:
- From the SystemLink Access Control >> Workspaces page, verify that the user has access to the necessary Workspace.
- Click on the ellipses next to the target Workspace and select Edit Workspace to view a list of members.
- Ensure that the user is only given one Role per Workspace.
- It is improper to set multiple Roles for a single user within a single Workspace.
- Select a Role that provides all privileges necessary. If a default Role does not meet this need, create a Custom Role instead.

- Ensure that you are not unnecessarily creating Role Mappings for the user.
- Role Mappings should only be used when SystemLink is configured to allow users to sign in using Windows accounts, LDAP or SSO.
- Unless one of these technologies is in use, it is not necessary to create a Role Mapping, and doing so may conflict with the settings applied within the Members tab of the Workspace settings.
- Ensure that the selected Role is correct.
- From the Systemlink Access Control >> Roles page, click the ellipses next to a specific Role and select View Role.
- On the Privileges tab, select the functionality of interest from the drop-down menu and verify that a check is present for the exact task that the user should be capable of executing.

- Check that whatever data your user intends to see/control is stored in the correct Workspace.
- For example, if your user should be able to execute Analysis Automation Procedures (ANP) and tasks, select the Measurement Data Analysis >> Analysis Automation page and verify that the data is stored in a Workspace that the user has access to.

- If SystemLink is configured to use Windows Active Directory, LDAP or SSO, verify that the problem does not stem from your user directory by testing a user stored within the NI Web Server instead.