Using invites

This guide is designed to get you inviting users to use your Talis Aspire Reading List tenancy.


Before sending invites we suggest you read the What is a role and what is a permission? article first to understand the roles that apply to the tasks the user will be carrying out, also to enable you to make changes in the permissions associated with each role in order to match your university’s workflow. When you have done that you are now ready to invite users.

To scope or not to scope?

Sometimes you only want to allow users to perform a role on a specific list/s. For example, you might want to grant an academic the list publisher role, but you only want them to be able to perform this role over one list in the system – you don’t want the academic to be able to edit other academic’s lists! This is where scopes come in.

Scoped List Publisher invites

To send a user an invite to be a List Publisher but with a scope limited to only a single list, administrators would invite a user to become a List Publisher via the list page which will only allow them to accept the invite scoped to that individual list. Currently, only the List Publisher role can be scoped. All other roles apply to the whole tenancy.

Tenancy wide invites

Any invites issued in this way will be scoped at tenancy, i.e. if the user accepts, they will be able to perform the activity anywhere in your Aspire tenancy. All Invites can be viewed on the Invitations tab.

To initiate invites for roles without scopes:

  • Select 'Roles & Invites' from the 'Admin' menu.
  • Click on the 'Roles' tab, to see the list of the roles, as well as the current permissions for each role.
  • Click the actions button to view the menu, then click the 'Send invites' button.
  • You'll then receive a screen prompting you to enter an email address/es for the role invite.  You are also able to edit the default text sent in the invitation email.

For information on accepting invitations, see Accepting a role invitation in Talis Aspire.

Top Tip

It is important that you ensure the email address used for the invite is the email address the user will enter on their profile, this is how the invite is then matched to the user in order for them to accept. If your institution uses more than one version of a email address, for instance,, or even, then encourage users to add all versions to their profiles to avoid mismatched invites.

Anything else I need to know?

Thinking invites are too time consuming for the wider rollout? Consider a Mini Project: Devolved Constraints and Devolved Entitlements and let the system do the hard work. Raise a support ticket for more advice.

Points to note

  • Role titles can’t be changed from the default titles, though please do raise a ticket with support, so we can discuss options on this.
  • For each list created by a List Creator role, the creator will also inherit permissions of the List Publisher role scoped only to the created list.
  • If a user is only given List Publisher role scoped at List level and not List Creator, they will not get the Create List permission enabled on their 'My Lists' page. List Publisher role scoped at tenancy will get Create List permission if enabled for that role as per the default settings.
Have more questions? Submit a request


Please sign in to leave a comment.