First determine whether the user cannot log in at all or whether some information is missing after login. These situations require different checks. Ask the user which application, customer account and login method they are using, and what error message they see or what content is missing.

Open the user's details in the correct customer account

Log in to the organisation's admin portal as an admin user. Open Manage user accounts > List of users and click the user's name. Check the email address in the User information section. Having the same email address in another customer account does not mean the user has access to this customer account.

You need edit permission to change user information. Save your changes using the Save button at the bottom of the form and make sure you receive a notification confirming that the update succeeded.

Check application access and account locking

A user may have access to the mobile application, the browser application or both. Android and iOS use the same mobile access permissions.

  • In the Mobile credentials section, check that mobile credentials exist and check the Active / Not in use switch.
  • Similarly, in the Admin portal credentials section, check that browser credentials exist and are active.
  • If the section only shows Add mobile user credentials or Add admin portal credentials, the credentials for that application are missing. Add the required access and configure the credentials and roles. See adding a user.

Not in use is an inactive state specific to an application: the credentials are retained, but they cannot be used to log in to that application. Active credentials for the other application do not compensate for missing or inactive credentials. Inactivity is different from deleting a user or locking the shared account.

Account locked in the User information section applies to the shared user account. The account is locked when the password login attempt counter reaches five. Mobile and browser password logins use the same counter; a successful password login resets it.

Once you have identified what is preventing login, clear Account locked and select Save. Saving resets the attempt counter, clears the locking time and records the unlocking time. It does not create missing application credentials, activate inactive credentials or grant content permissions. Confirm the correct password and login method before trying again.

Check the login method and which message is needed

For a forgotten regular password, use the password reset instructions. Users who log in through their organisation's Microsoft or Google login must select the correct login method. Changing the Spotilla password does not resolve a problem with the organisation's identity service.

There are two different ways to send a message at the bottom of the user form. Check the recipient's address before sending. A message for an admin user is sent to their contact email address.

  • Update changes and send login information to user by email appears when the password fields are filled in. It saves the changes and sends the login information. The application-specific login links included in the message depend on the new passwords provided when saving. Selecting Save alone does not request this email.
  • Send one use sign-in links. generates new links for existing active application credentials. It does not require a new password and does not itself save other changes to the form. This action requires an admin user. No link is generated for inactive or missing application credentials.

A one use sign-in link is not a permanent password. The mobile link and QR code can each be used once and are valid for seven days. Using a browser one use sign-in link invalidates the user's other browser one use sign-in links as well. Ask the user to check their spam folder if the message does not arrive.

Use logs to investigate the situation

Select Check user's logs in the User information section. The tabs in the Logs window show different information:

  • Mobile user shows mobile usage events, including the device and timestamp. Android and iOS send usage information from the browse view; a location is shown only if the event contains location information.
  • Manager user shows events generated by browser logins, including the browser, IP address and timestamp.
  • Active mobile sessions shows mobile login sessions separately. These rows should not be interpreted as usage log events.

The log is not a complete list of failed login attempts. An empty log therefore does not mean that no login was attempted. A session's Last used at time should not be treated as an exact timestamp for every individual use either.

If a mobile session needs to be invalidated, open Active mobile sessions, click the trash icon on the relevant row and confirm deletion. This action deletes the login token for that specific session. The application can no longer use it for service requests and must log in again. The action does not delete the user, change roles or delete other sessions. Admin users can delete users' sessions; users can delete their own.

If the issue concerns multi-factor authentication

Spotilla's browser multi-factor authentication is separate from the phone's PIN or biometric application lock and the additional authentication required by the organisation's login service. The action in the user information form does not remove these other protections.

When a user has Spotilla multi-factor authentication enabled, Deactivate Multi-factor authentication appears at the bottom of the user form. This action requires an admin user and permission to edit the user account. Click the button and accept the confirmation only to resolve this authentication issue.

Deactivation clears the current authentication settings and deletes the backup codes. The old authenticator app configuration and old backup codes can no longer be used for authentication. If authentication is enabled again, the user must set it up anew and save the new backup codes.

The confirmation window says that authentication will need to be set up again at the next login, but this should not be treated as a rule that applies to all users. After deactivation, the requirement is retained for an admin user only if the customer account requires multi-factor authentication for admin users. For other users, the setting is disabled. See setting up authentication.

If login succeeds but content is missing

First check the customer account and the view's status, date range and search filters. If needed, use the instructions for switching customer accounts on mobile. An admin user's own view does not indicate what a regular user is allowed to see.

Check the application-specific Permissions (roles) in the mobile application and Permissions (roles) in admin portal on the user form. A browser role does not replace a mobile role, or vice versa. A user can belong to several roles, so check all roles for the application in question.

The tabs further down the form, User's roles, User's permissions for folder trees and Other permissions on Spotilla, help you check the full set of permissions. To change a role's permissions, go to Manage user accounts > User roles. The change also affects other users who belong to the same role.

For a missing Spot, check that the role grants read permission to the correct folder or one of its parent folders. Folder permissions extend to subfolders. Permissions granted by multiple roles are combined. The mobile Tag read only permission does not grant normal access to browse all Spots in that folder tree. See mobile roles and folder permissions or manager user permissions.

If the Spot is visible but a task is missing, check the parties responsible for the task and whether the user belongs to the responsible role. On mobile, permissions can also come from folders if Show tasks based on folder permissions is enabled in the Visibility of tasks to non-responsible parties setting on the Settings page. The same setting can allow all mobile users to view open, late and in-progress tasks or completed tasks. This expands visibility across the entire customer account, so do not change it to resolve one user's issue without assessing the impact on others.

On mobile, these permissions do not make planning-stage drafts visible, nor do they make tasks without a valid responsible party visible. Being able to see a task also does not guarantee all permissions to work on it. Also check task views and filters.

Service request visibility must be checked separately under Service requests > Service request settings by opening the request type. For the browser application, check the manager's processing and observer roles. For mobile, check the request's responsible role, the request type's observer roles and the separate permissions for open requests and requests that are On hold. Being able to see the Spot or create a service request does not guarantee that a saved request will be visible. See service request visibility and permissions.

Verify the result of the fix

Save the changes and ask the user to try with their own credentials in the correct customer account and in the application where the issue occurred. Verify separately that login succeeds and that the previously missing Spot, task or service request is visible. If the issue also affected processing, check that the required action is available. Successful login alone does not confirm that content permissions have been fixed.