When resource names or links do not suit your needs

Sometimes the name and description on a resource does not fit perfectly with what you get from that supplier, and your patrons might not realise quite what they can access.

This usually only affects MyAthens and there are a couple of ways of dealing with this if it comes up: 

When you subscribe to only one item from the resource

When you only have one target, the best approach is usually to edit the title and description of that resource. This is simple and quick but would need to be repeated by any sub-administrators who also used the same resource (which has the bonus that they can name and describe it differently if they need to). If the resource supports deep linking you might also modify the access URL to go to a more desirable landing page. This is a popular method for organisations that access the Cochrane library via Wiley.

Statistics are still displayed under the resource's official name.

When you subscribe to several items from one resource

This could come up if a resource landing page features several journals or items of which you have access to a few (e.g. BMJ, OUP), or if a service provider has moved several resources behind a single entityID (e.g. ScienceDirect, Clinical Key, Scopus).

Whilst you could still edit the resource name and description, the better approach in this situation is usually to create custom resources that link to relevant landing pages for each item. These custom resources can be made available to sub-administrators and you can cascade them to default permission sets if you choose. If you are using restrictive mode you must still allocate the original 'real' resource to the same permission sets or the accounts will be denied access by the system.

Statistics are still displayed under the resource's official name – unfortunately there is no way to link statistics to specific custom resources.

Depending on why you are doing this, you may not want your users to see that original resource in MyAthens. In restrictive mode it cannot be removed from the permission set without affecting access, so you can set it as hidden from users via the details view. The visibility setting on a resource is per administrator, so sub-administrators can choose if visible or invisible is best.

Process

1. Create and test the links you want to use for your custom resources. For the best user experience these links should pass through authentication and be a modification of the main access URL but if the resource does not support deep linking you may have to use the same link. Redirector links, where available, can be useful here.
2. Create custom resources at your highest login level and set the links from step 1 as the access URLs
   1. You can make them available to sub-administrators via the visibility tab on the resource details page
3. Allocate the custom resources to the permission sets you want them in
   1. If in restrictive mode also allocate the original resource
   2. Cascade to default permission sets if you choose (this will make them visible to sub-administrators if they are not already)
4. Make the original resource hidden from users if you choose
   1. Have each sub-administrator repeat step 4 as required.