Hirers and agency admins with invitation permission can open an active, unverified user's profile and choose Invite user. Send invitation email sends the invitation to the user's registered email address. Copy invitation link creates an invitation without sending an email and shows the login email, link and expiry. Agency admins can invite users within their own agency; hirers remain limited to users they can manage within their organisation.

Use the copy icon beside Invitation link to copy just the link, or review the Invitation message preview and choose Copy invitation message. The preview shows the exact text that will be copied and can be collapsed. The message includes the registered login email and setup instructions, so it can be sent individually to a confirmed alternative inbox. Receiving the invitation at another address does not change the user's login email. Password resets and other account emails continue to use the registered address.

Password setup links expire after seven days and can only be used once. Generating another invitation replaces the previous setup link. Anyone holding the link can set the account's password, so share it only with the intended recipient. Link generation is recorded in the user's activity history.

Users required to sign in with Microsoft receive a sign-in link and instructions instead of a password setup link. Their organisation's SSO rules still apply. Invitations for users of a branded portal use that portal's address.

​

Hirers can select Filter in the Users page header on the Company tab, choose a standard company or project role in the slide-out dialog, and select Apply. The filter applies across all results and works with search. Applying or clearing a role returns to the first page. Reopen Filter and select Clear to show all roles again.

Agency admins can use the same Filter button and slide-out dialog in their own Users list to select Admin or User. The hirer's Agency tab lists agency contacts and does not offer this role filter. Custom company roles are included under their base role.

​

Hirers can retrieve project-role users and their assigned projects through GET /companies/{id}/user-assignments or the open_api_list_company_user_assignments MCP tool. Effective project permissions are available separately through GET /companies/{id}/user-permissions or open_api_list_company_user_permissions. Both require a company-scoped key with read:users access. Results include inactive users by default and are paginated by user. Add status=active to either route, or set status to active in either MCP tool, to retrieve only active users. Use status=inactive for inactive users. Pagination totals reflect the selected status. Only projects belonging to the requested company are returned, identified by project id and name.

Hirers can inspect default role permissions through GET /access-rule-mappings or the open_api_list_access_rule_mappings MCP tool with a valid company-scoped key; use groupBy=role to collect defaults by role, or groupBy=rule to collect roles for each action and configuration key. Omit groupBy for individual mappings. Filters apply before grouping, and pagination totals count groups when grouped. This reference covers company and project role defaults. These are global RBAC defaults, not user-specific project permissions. Agency-scoped keys cannot access this reference.

These permissions use the same project-level rules as the UI permission export. Additional workflow and record-level restrictions can still apply. Agency-scoped keys cannot access this report.

​

Company admins can open the company’s Users page and choose Actions > Custom roles to create or rename a role such as Contractor Requestor. Click a role row to edit its name; Delete unused role is available in the edit dialog. A custom role needs a name and a base role: Project Requestor, Project Approver or Project Finance. The base role stays in place for project membership and workflows. Role names must be unique within the company regardless of capitalisation and cannot match standard role names or codes. A user can have one custom role per company. Users connected to multiple companies keep one shared base role; company admins can only select roles within that base role so changes do not affect another company. Contact support if the shared base role needs to change across all connected companies. A shared base-role change removes incompatible custom roles and applies the new role’s permissions in the affected companies. On the user profile, the Role selector includes standard roles and the company’s custom roles. In Actions > Custom roles, enable Hide standard roles when custom roles exist to hide each standard role that has a custom alternative in that company. This setting saves automatically. Standard roles without custom alternatives remain available, and existing user assignments are unchanged. Selecting a custom role also sets its base role automatically; selecting a standard role clears the custom role for that company.

Custom roles appear as tabs on the Users page, including roles with no assigned users. Custom roles are available in Export Users and Export User Permissions to users who already have access to those features and the selected company. Company admins can also select them in the Manage Users role filter. Reading role names does not grant permission to configure roles. Manage Users shows the company role name and supports assigning or removing those users from projects using their base role. Exports use the role assigned in the selected company and show its name; selecting a standard role includes users without a custom role in that company. Users assigned to a custom role appear in its tab rather than the standard base-role tab for that company. The Users table and the sidebar profile card display the custom role name for the selected company, falling back to the base role when no custom role is assigned.

Choose Actions > New Permission Template and select the custom role in the Role field. When creating a template, permission toggles appear after selecting a role and start with that role’s base permissions. Changing the selected role resets the toggles to its defaults. Templates for standard roles and custom roles are separate. For approvers, templates also match the approval stage. Without a matching template, the custom role uses its base-role permissions. Use Apply to Matching Users to apply a newly created template to existing users. Future project assignments use the matching template automatically.

Creating or editing a template saves it without changing existing users’ permissions. Use Apply to Matching Users to update active users matching the role and, for approvers, approval stage. This applies equally to standard and custom roles and replaces individual permission settings for the affected company. Future project assignments use the latest saved template. Deleting a template leaves previously applied permissions in place; future assignments without a matching template use base-role defaults.

Select custom roles in the company Access Control page to configure data restrictions. Assignments rules can select multiple items in one rule: KID, SDC, SDS and individual custom documents. Custom document descriptions appear beneath their names in the Items dropdown when provided. When Hide standard roles when custom roles exist is enabled, the Restricted Roles field hides each standard role that has a custom alternative in that company. Standard roles already saved on a rule remain available when editing it. Restrictions on the base role also continue to apply.

Select a company role when creating or editing a user. Enter a standard role value or the name of a role configured for the selected company in each spreadsheet row’s Role column. One file can contain different roles. Roles based on Project Approver use the profile’s approval-stage selector when stages are configured, and accept the Approval Stage column in imports in the same way as Project Approver. Leave it blank for the default first stage; explicit stages must be whole numbers from 2 to 4 and within the company’s configured stage limit. Invalid stages reject the import before users are created. The import dialog and View Instructions list the available values. Existing import restrictions for mandatory user tags still apply. A role cannot be deleted while assigned to users or referenced by permission templates or access rules.

Agency-supplied contractors who use hiring-company project accounts can be assigned these roles by the hirer. Agency accounts retain their separate agency permissions and client/project access; agency admins do not configure the hirer’s custom roles.

​

For hirers and agencies, the notification list on a branded portal includes only notifications linked to clients and projects you can access on that portal. Client notifications without a project can also appear. Marking a notification as read or using Clear All applies only within that access scope.

For hirers and agencies using password sign-in, enter your work email and select Continue to reach the password step, then select Forgot password? to request a reset email. The recovery link appears only on the password step. For sign-in help, select Having trouble signing in? Contact support below the sign-in options. On the main Requidex site, this opens an email to [email protected]; branded portals use the provider's configured support email. An expired, invalid or already-used password-reset link shows a message asking you to request a new link. Return to the sign-in page and request another password reset, then open the new email link. A successful reset link can only be used once.

For hirers and agencies, open your Requidex website address to sign in: the sign-in form appears at the site root, including on branded portals. Existing /login, /auth and configured branded sign-in links redirect to the site root and retain their sign-in options and return destination. If your portal is hosted under a path, use the root of that portal path. When you are already signed in, opening the site root takes you to your usual landing page.

Hirer users may receive a branded sign-in address from their provider. Each client belongs to at most one white label, so hirers and connected agencies use the same branded site for that client. In the Companies list, a chip beside the company name identifies its white label. Agency access follows existing client connections and user permissions. Agencies can sign in to each branded site containing a client they can access, and see only permitted data for clients assigned to that site. Agencies with at least one permitted non-white-labelled client can also sign in at app.requidex.com and see all their permitted clients there, including white-labelled clients. On a configured site, the sign-in page and main navigation use the provider's product name and logo, with black and white navigation colours. When a provider sets a brand colour, hirers and agencies see it on primary buttons, icons and highlights in both light and dark mode. Without a custom colour, the standard platform colours apply. The browser title, notification titles, account-switch messages, onboarding invitation prompt and downloaded MFA backup codes also use the provider's product name. Hirers and agencies see neutral platform wording in worker consent, document validation, user import and integration messages. Worker consent requirements remain the same: written consent is required before adding or accessing a worker’s personal information. Hirers and agencies see the provider’s browser-tab favicon. Providers can supply separate versions for light and dark browser colour preferences; the browser preference selects the icon independently of the app theme. If only one version is supplied, it is used for both. The standard logo appears on a white header. In dark mode, a separate dark-mode logo uses a black header; without one, the standard logo keeps its white header. Company branding controls are hidden for clients assigned to a white label because their site uses the provider’s branding. A provider may also show its own image beside the sign-in and password forms on larger screens. Hirer and agency users sign in to branded sites with their email and password. Microsoft sign-in is only available on the main Requidex site; branded sites do not show the Microsoft button or redirect users to Microsoft after entering an email address. Use your existing account details; the client or agency entry link does not change your role. On a branded site, client selectors show only clients enabled by the provider that your account already has access to. This client restriction applies to hirer and agency users, including searches, exports and direct record links. If no clients are available, contact your provider. Hirer users cannot be connected to both white-labelled and non-white-labelled clients. Remove conflicting client connections before assigning a hirer user to the other type; project assignments follow the same rule. Agency users can work with both types using the same account. Agencies connected to several branded clients use the respective sites. Agencies connected only to branded clients cannot sign in to the main site. Agency users with no accessible clients can still sign in to the main site, but cannot access client records until client access is assigned. Hirer accounts connected only to white-labelled clients must use their client’s branded sign-in address. After a hirer or agency user enters their email, the sign-in page checks whether they can access the current site. If they cannot, it keeps the password field hidden and shows the portals their account can access. For hirer and agency accounts, Main Requidex is offered only when the account has a non-white-labelled client. Accounts with several branded clients can choose the relevant portal. No credentials are transferred; sign in again at the selected site. Each session belongs to the website where you signed in. Microsoft sign-in creates a main-site session and cannot be used by accounts restricted to branded sites. Sign in again when switching portals. Existing hirer and agency sessions on the main Requidex site continue without a fresh sign-in for users who retain access to that site. Main-site eligibility is checked at sign-in and when the session refreshes. If client branding or account connections change, an existing main-site access token remains valid until it expires; the next sign-in or session refresh checks the updated eligibility. Existing company, project and agency permissions still apply during the session. Previously issued invitation and password-reset links remain usable until they expire or are replaced, and can only be used once. For hirers and agencies, records on a branded portal are limited to that portal’s permitted clients. On the main website, hirer and agency user lists, user search and project contacts follow existing company, project, agency and MSP context and permissions. A contact is not hidden simply because their client uses a branded portal. Client-related emails use the client’s saved branding, including scheduled notifications and reply-to address. On branded portals, hirers and agencies receive neutral delivery links for attachments, invoice PDFs and export downloads, including existing files. Main-platform links retain their existing addresses. Emails with client branding also use neutral file links. Branding images and new uploads from branded portals also use neutral URLs. Receipt links inside expense exports requested on branded portals use the neutral delivery address; main-platform exports retain their existing receipt links. A custom sender address is used only when the email service confirms that address or its domain is verified. Otherwise, emails use [email protected] with the configured sender name, including when verification cannot be checked. Your provider can set up the sender from the white-label configuration, view the required DNS records and check verification again after those records are added. DNS verification can take up to 72 hours. Summaries spanning clients use their shared branding only when all clients belong to the same portal; otherwise they use Requidex branding. Agency invitations use the white-label branding and password setup address when all clients the invited user can access belong to the same white label. Account messages spanning several portals also use Requidex branding.

Emails triggered while using a branded site, including password resets and invitations for hirer and agency users, use the provider's name and logo. Links in these emails return you to the branded site. Help & Support uses the provider's configured support website and email address. Policy links appear when supplied by the provider. On branded sites, the user menu hides Integrations for hirer and agency users. Hirer company admins can open Change Requests from the user menu on branded sites. The Integrations page is unavailable, including through direct links. Out of office does not offer Connect Outlook; new Outlook connections cannot be started from a branded site. If you see a 404 Page not found screen, check your sign-in address or contact your provider.

​

The project Users page displays one role table at a time in tabs. Standard tabs are Admins, Finance, Approvers, and Requestors and appear when they contain users. Company custom roles have separate tabs, including roles with no users assigned to this project. Users with a custom role appear in that tab instead of its standard base-role tab. Permission and removal actions still use the base role. These assignments control which project-role users can see and work with the project. Agency staff access remains separate from these hirer user tabs.

​

​

Use the project action menu to assign Project Admin, Project Finance, Project Approver, or Project Requestor users. The available assignment actions depend on your permissions. Assignment emails show the project name in the subject for one project, for example Assigned to project (BCC PM South Kitchens 26/27), or the number of newly assigned projects, for example Assigned to 3 projects.

When creating a hiring-company project-role user, select the company and search the Projects selector by project name or code. Codes appear before project names where available, and searches are case-insensitive. Select the projects the new user needs access to. Agency staff access is managed separately through Connected Clients.

​

Only Company Admins can open an existing project user’s profile and enable Auto-assign to new projects, then save the profile. The toggle applies to the company currently selected by the admin. It is off by default and is saved separately for each company the user belongs to.

Active users with this setting enabled are assigned to new projects in that company, including imported projects, using their current project role and the applicable permission templates. Inactive users are skipped. Enabling the setting does not add existing projects, and disabling it does not remove existing assignments.

Removing a user from a company clears that company’s setting. Changing the user to a non-project role clears their automatic assignment settings. Agencies cannot manage this setting; their client and project access is managed separately.

​

Companies can configure user tags for project-role users. If any user tag is marked mandatory for the company, creating or updating a project-role user requires at least one valid user tag for that company. User imports for project roles are unavailable when mandatory user tags are configured because the import file cannot assign tags. Hirers and agencies with permission to manage the selected company must create those users individually and select the required tags.

When a requisition or assignment has a user tag, project-wide notifications about its creation go only to project users with that tag for the hiring company. Project-wide timesheet approval requests follow the linked assignment's tag. Hirer approvers chosen for a requisition or assigned specifically to a timesheet still receive their approval notifications. Agency recipients and manually addressed messages continue to follow their existing access and notification rules.

​

The API supports assigning and removing multiple users across projects. Bulk changes update project membership and clean up project-scoped permissions for removed projects.

The user assignments export uses the shared export naming format: user-assignments, the company scope, and the export date, for example user-assignments-acme-ltd-23-05-2026.xlsx.

​

System Admin and Agency Admin users can restrict an Agency Admin or Agency Staff user to selected connected client companies from the user's Connected Clients tab. Agency Admins can also manage their own client and project access from their profile; Agency Staff users still need an Agency Admin or System Admin to make these changes.

They can also expand each enabled client in the Connected Clients tab and restrict the user to selected projects. All active projects belonging to that client are available for selection. Client and project access are saved separately per agency. Selecting every available item leaves that part of access unrestricted. Clearing one or more projects limits project lists and project-linked records, exports, filters, mentions, and notifications to the selected projects.

A project's client must also be accessible. Removing client access therefore removes visibility of that client's projects even if a project remains selected. Existing agency users keep unrestricted project access until their project selection in Connected Clients is changed.

​

Users can be removed from project access through the project user tables or, for project-role users, by using Remove from the Projects list. Removal also cleans up project-scoped permissions for the removed project.

​

A project-role user can remove themselves only from projects where they are assigned in their current role. Project Admin, Project Finance, Project Approver, and Project Requestor each use their matching project user list for this check.

​

When a project-role user can see a hidden project in the list, they can request access. The request is sent to a company administrator for review.

​

Export User Permissions includes every active configurable permission, using its current name, for each exported user and assigned project. Values reflect role defaults and project-specific overrides. Max Requisition Approval Value shows the project's configured limit, Unlimited when approval is enabled without a limit, or N/A when approval is disabled. Hirers with export access can use this report to review project user permissions; agencies needing a hirer user's access reviewed should contact the hirer.

Amend Assignment Rate/Pay Type allows changes to the assignment's rate type, such as PAYE, CIS or PSC, and its hourly or daily pay type. Hirer and agency users still need access to the assignment, and the applicable company settings and workflow restrictions must allow the change.

Amend Assignment Dates controls Change End Date and Change Dates. Change Dates edits both the start and end dates for pending assignments; for confirmed assignments it is available when timesheet import is enabled. These date actions are not available for shift-based assignments. Other assignment status and workflow restrictions still apply.

The User Permissions dialog shows an explanation beneath each permission label, covering assignments, requisitions, timesheets and billing. Add expenses is separate from Amend Timesheets. The explanation about overriding rate access controls appears only for companies with a rates access control configured, including their selected projects. It allows hirer and agency users to view and add claims within their permitted scope even when rate access is restricted; pay and charge rates and restricted billing documents remain hidden. Existing expense amendments, approvals, deletions and invoicing retain their separate permissions and restrictions. Amend Timesheets includes requesting approval for individual timesheets and in bulk; Approve Timesheets includes approving timesheets, rejecting amendments and undoing approval. Hirers must enable Amend Timesheets for the relevant projects when a project user needs to request approval. Agencies needing a hirer user's permissions changed should contact the hirer.

When managing permissions across multiple projects, differing permission values are shown as Mixed. Only permissions changed in the dialog are saved to the selected projects; unchanged permissions and mixed approval limits stay as they are.

For hirers managing project users, setting a permission to No removes that permission for the selected projects while preserving access on other projects. Adding a user to further projects applies the company template to those new projects and preserves permissions on existing projects. Agency users needing a different timesheet approver should contact the hirer to update the relevant project user permissions.

​

When managing a user's project permissions, requisition approval can include a Max value. This value limits the total requisition value the user can approve for the selected project.

Leave Max value blank for no value limit. If a maximum is set, the user remains a requisition approver for that project but cannot approve requisitions above that value.

​

Timesheet approvers are loaded from eligible company admins and project users with timesheet approval permission. Eligible users must be active and verified. Project-role users must also be assigned to the project.

​

​

Access changes can affect project visibility, requisition approver lists, timesheet approver lists, project-scoped permissions, and project-scoped notifications immediately after the user list is updated.

Known users who are no longer assigned to the project are excluded from project-scoped assignment and timesheet comment notifications for that project.

​

Project user groups are made up of the hiring company's own users, so agencies do not appear in or manage them, but agency access is controlled separately.

​

GET /users requires read:users and returns users visible to the key owner within the API key scope. Hirers use company-scoped keys and agencies use agency-scoped keys. Company and agency administrators can list users for entities they manage. Project administrators are limited to users sharing their projects. Project finance, approvers, requestors and agency staff can retrieve only their own profile. Membership IDs returned with each user are limited to visible entities within the key scope.

Hirers can create company and project users with company-scoped API keys. Agencies can create and update their own agency users with agency-scoped keys. Both require write:users and a key owner who has permission to manage the users.

POST /users follows the portal workflow, including SSO email-domain checks, project or agency memberships, required user tags, notification settings, and permission templates. Set notifyUser to true to send the account invitation; it defaults to false.

PATCH /users/:id preserves fields omitted from the request. Every existing membership must be within the key scope and manageable by the key owner. Deactivating a user also revokes their API keys and removes them from approval routes. For both hirers and agencies, PATCH does not accept role, companyRoleId, or companyRoleCompanyId. Use PATCH /users/:id/memberships to add or remove memberships. Use the portal for your own account or changes to base roles and custom role assignments. For hirer project users, tag updates replace the selected company’s tags; any company supplied on a tag must match companyId. Agency users do not use project-user tags.

PATCH /users/:id/memberships adds or removes memberships through the same actions as the user record. Hirers use company-scoped keys for company users assigned to companies and project users assigned to projects. Agencies use agency-scoped keys for agency users assigned to agencies. Both require write:users and an active, verified key owner with permission to perform the membership action. The user must already have at least one membership within the key scope, and every requested company, project, or agency must be within that scope. The membership type is determined from the user’s existing role; requests supply only action and ids. The response identifies the membership type and reports counts and names for added, removed and skipped memberships for companies, projects and agencies. Company and agency memberships that are not assigned are skipped during removal without removal activities or notifications. The user’s role is preserved, and existing permission templates, removal cleanup, activity records, and notifications apply to changed memberships.

​

Hirers can read company-level access control rules through GET /companies/{id}/access-control-rules or the open_api_list_company_access_control_rules MCP tool using a company-scoped key with read:companies. Results include restricted roles or users, exempt users and restricted items and actions, with pagination, search and field selection. Custom roles are identified as companyRole:<ObjectId>. This is saved company configuration, not a complete report of effective user permissions; project, agency and user overrides are excluded. Agency-scoped keys cannot use this company endpoint.