Revoke a user's access in the browser as an administrator. Mobile and admin portal access are separate: disabling one does not disable the other. Before making changes, check which applications the user uses and who will take over their unfinished work.

Choose the appropriate change

  • Not in use prevents use of the selected application but retains the application credentials, user account and role memberships. This is suitable for suspending or ending access when you want to retain the user's details.
  • Removing a role membership limits the permissions granted by that role and may change the assignees of work that follows the role's membership. It does not prevent login. Other roles and responsibilities for individual jobs may still grant access to information.
  • Delete credentials deletes the selected application credentials and their role memberships. The shared user account and any credentials for the other application are retained.
  • Delete user deletes the shared user account and its associated application credentials. Deletion also changes links to retained data, so some historical information will change.

Disable mobile or admin portal access

  1. Open User management → User accounts and click the user's name.
  2. Find Mobile credentials or Admin portal credentials on the form. Change the Active switch at the top of that section to Not in use.
  3. To prevent use of both applications, change both switches.
  4. Click Save at the bottom of the form.

The status switch and application-specific delete button for an administrator's admin portal credentials are hidden. The switch instructions for a regular manager user therefore do not apply to disabling an administrator's admin portal access.

Disabling mobile credentials invalidates the server's login tokens and prevents new logins. In the browser, a disabled account is logged out on the next server request, and normal login is blocked.

Android returns to the login screen when it detects the server's notification that the session has been invalidated. iOS displays a session invalidation notification and starts unsubscribing from notifications. The screen or local data on an offline device may not change immediately. Revoking access does not remotely erase the device's data.

Not in use does not transfer tasks to a successor or remove the user from roles or resource allocations. If access must be revoked immediately, save the status change and arrange the transfer of work responsibilities separately. Access can later be restored using the Active switch in the same section and saving; mobile users must log in again.

Limit permissions by changing roles

The credentials sections of the user form contain the fields Permissions (roles) in the mobile application and Permissions (roles) in admin portal. Remove the unnecessary role from the selections in the relevant field and click Save. You can also remove a role membership using the trash icon on the role's row in the form's User's roles section; save afterwards in this case too.

Removing the last member may be blocked if the role is needed for responsibilities in work or other settings. Add a suitable successor to the role or change the responsibility associated with the dependency before removing the membership. Setting credentials to Not in use does not empty the role or resolve these dependencies.

A role change saved on the user form updates the assignees of tasks and group tasks that follow the role's membership, along with their resource allocations, in the background. The update also applies to maintenance templates, offer settings and contract resource allocations that follow the role's membership. Changes to task assignees may extend to completed tasks. Changing only the status switch does not trigger this role change if memberships remain unchanged.

You can also change role members by opening the relevant role under User management → User roles. The search used for the task assignee update started from this view excludes completed tasks. After the change, therefore, check both memberships and the assignees of the relevant work. More detailed instructions for defining permissions are available in mobile roles and folder permissions and manager user permissions.

Delete credentials for only one application

Click Delete credentials at the bottom of the relevant credentials section on the user form. The section is hidden from the form, but the deletion takes effect only when you click Save at the bottom of the form. This does not delete the entire user account.

The delete button may be disabled, and the section may display a warning about the user's responsibilities in tasks or service requests. Resolve the responsibilities and signature settings before deleting. The button being visible does not by itself guarantee that saving will succeed.

Deleting application credentials removes their role memberships. Deleting mobile credentials also removes login tokens, login service connections and mobile usage logs. Author references in messages and comments, and responsible-person references in tasks, are cleared for the deleted application credentials. Deleting admin portal credentials also clears the user reference in reservations. This action does not delete time entries linked to the shared user account.

If access is needed again later, it is added as new application credentials. See adding a user and credentials.

Prepare to delete the entire user account

Arrange a successor and check for anything blocking deletion before deleting permanently:

  • Ongoing time entries: end general working time entries and entries started for tasks and service requests that have no end time. If necessary, correct an entry using the instructions for recording working time and correcting a time entry.
  • Work Alone Protection: the user's protection configuration and active Work Alone Protection sessions prevent deletion. End the sessions and remove the user's protection configuration.
  • Unfinished tasks: check work where the user is the only assignee, as well as work that uses their single-member role or follows its membership. The check is not limited to the Open status: it treats all tasks other than completed tasks as unfinished.
  • Resource allocations for templates and recurring work: check task templates, recurring task resource allocations and hourly maintenance templates where the user is the only directly assigned person or the only member of a required role.
  • Offers: assigning the user in an offer's task settings prevents deletion when the offer is in Opportunity, In Progress or Offer Sent status. Leaving a role may also be blocked if the user is the last member associated with these settings.
  • Contracts: check resource allocations in task settings where the user is the only directly assigned person or the only member of a role being used. Archived and deleted contracts are excluded from this deletion check.
  • Signatures: check signatures assigned to the user in tasks, service requests, task templates and service request categories. If deletion displays a signature warning, address the items named in it before trying again. Do not assume from the work's status alone that the signature dependency has been removed.

If a deletion attempt opens a dependency view, expand the group for the relevant reason and click the item's Name link. If a Role link is present, it opens that role. Change the responsibility or setting in the item's own details and save it. In addition to adding a new person, you may need to remove the old user from the setting. Disabling access does not replace these changes.

Delete the user and account for the effects on data

Click Delete user at the bottom of the user form and confirm deletion. Alternatively, use the trash icon on the user's row in the user list. Both actions start deletion of the entire user account.

In addition to application credentials, full deletion removes the user's work week and weekly resource settings, usage logs, assignee associations and resource allocation rows. It does not mark tasks as completed or automatically transfer responsibilities to another user.

Time entries, signatures and signature settings are retained, but their links to the deleted user account are cleared. User associations in some inventory data and other costs are also cleared. A retained time entry may therefore no longer display the user's name. In the working time calendar, user details are retrieved from the current user account, and an entry without a user reference is not included in data filtered by the former user's identifier. Deletion therefore affects how personal information is displayed and how data is filtered by person, even if the entry itself is retained.

To delete multiple users, select the checkboxes on their rows in the user list. Open the Actions menu in the checkbox column header and select Delete selected rows. Confirm deletion. The action processes users individually: some may be deleted while others remain because of dependencies. Check the number deleted and the separate dependency view for users whose deletion failed.

Check the result

  • Reload the user list. A disabled user is still listed; open the form and check the status of the relevant credentials. When credentials for one application are deleted, the user account should remain and only the deleted credentials should be missing. After full deletion, the user account should no longer be found.
  • Check that access to the selected application is blocked by making a new request while online and trying to log in again. If you disabled only one set of credentials, also check that access to the other application works as intended.
  • Check the assignees and resource allocations of transferred work. After the background role update, also verify templates and other settings that follow the role's membership.
  • Check a representative time entry and any required view filtered by person. A deletion success message alone does not show that historical information is displayed in a way that meets your needs.

If access or visibility does not match the change you made, see investigating a user's access.