Skip to end of metadata
Go to start of metadata

From time to time your patrons might report problems accessing resources. Usually it is something that can be quickly and easily resolved yourself like a forgotten password, but occasionally not. Here is how in general to find out what is up and what to do. Hopefully steps 4 and above will rarely be reached.

  1. Ask the user which resource they are trying to access
    1. If it is one you subscribe to, and you are using restrictive mode, check that it is in one of the permission sets allocated to that user and add it if necessary (it will be a few minutes before this takes effect everywhere)
    2. If it is one you subscribe to, and no one has gained access at all, check that the provider has enabled remote access for you. This will usually be referred to as federated access unless it is a specialist resource only available via the proxy
      1. In the unlikely event that there is any confusion over which catalogue resource it should be, talk to your OpenAthens support provider
    3. If it is one that you do not subscribe to, then the user correctly did not get access, however you should still:
      1. Check that the resource is not listed in any permission sets
      2. Consider if you need to turn on restrictive mode
      3. Ask the user why they're trying to access that one in case you have a link on other pages you control... or want to consider subscribing
  2. Check the activity tab on that user's account
    1. If nothing is there, the user is either not signing in at all, or is not using that account's username / email address. Remind the user of their ID and reset the password if necessary
    2. If activity is there you will see if they have been entering the wrong password or if they've been stopped for other reasons
  3. Attempt access with your own account, or ideally a test account that uses the same permission sets as the user's account. If the user is present, watch them attempt access with their account
    1. If access is achieved, educate the user
    2. If access is not achieved, assess what is blocking it
      1. Our error messages will look different from the resource's error messages
        1. If the URL in your browser starts with something like, the error message is from us. They are usually self-explanatory, but if you do not understand the message contact our service desk
        2. If the URL in your browser starts with the resource's domain, then the message is from them. They are the best people to talk to if you are unsure what the error means
        3. If the URL in your browser starts with your own domain, then the message is from your own IT team
  4. If the resource is one you subscribe to and is not providing the required level of access, contact the service provider. You will probably have to tell them your organisation identifiers
  5. If the resource is one you subscribe to and the error message says anything about attributes, you have either not set the expected role or entitlement attributes on the permission set(s) used by the account, not allocated the relevant permission set(s) to the user, or not set them as releasable. The service desk can help you if you are unsure but this will be one of two things:
    1. If it is only affecting one user who should have access, then the account does not have the correct attributes or permission set(s) assigned
    2. If it is affecting all users, then the permission set(s) do not have the correct attributes assigned to them or the release policy does not release them
  6. If you are still not getting as far as the resource and are getting an error message from us, first check the service status page and if there is nothing there to suggest there is a known problem that is being fixed, then contact our service desk

These have been ordered by the general likelihood of where a problem is. You will know your set-up and patrons best and may find a different order suits you better.

If you are contacting our service desk, there is some information that they will always require to investigate an access issue and supplying it when you log the call means they will not have to ask you for it and everyone can avoid the delays that such clarification questions can bring. The things they will always need to know to start looking at any access problem are:

  • An example of a username that has failed. Do not send the password.
  • The date and time that username failed (within a few minutes is close enough)
    • saying 'every time' or 'always' is unfortunately not as helpful as you might imagine as we have to find references in various logs that cover millions of events per day
  • The name of the resource you are accessing
  • The URL and text of any error message

Some other bits of information that may occasionally be needed which you could include if you have them to hand, are:

  • The type of resource (federated, proxy, etc)
  • The sub-organisation you were acting as (if you were)
  • If you have modified the access URL of the resource in the catalogue, please include that too
  • Any steps to recreate if it happens via one method and not by another
  • No labels