To effectively use XRAS, you must understand the six core concepts described in this section. The workflow assumptions built into XRAS are based on the concepts of projects, allocations, requests, roles, transactions, and opportunities. We define and describe them here since they affect the rest of this document.
Projects
The concept of a “project” is central to the value XRAS provides to your allocations process. A project, assigned a unique identifier (in a format of your choosing), encompasses all the requests, allocations, reviews, and transactions spanning the history of a line of work supported by your institution’s resources. Projects may be short and consist of a single request (e.g., a project to support a single training course or workshop) or long and encompassing many requests (e.g., a project spanning many years of research by the same lead investigator). The linkages provided by projects let you easily see the history of a project and allow reviewers to look at prior requests and reviews to see if progress has been made or if previous reviewers’ concerns have been addressed in the latest submission.
Allocations
It would be difficult to have any discussion about XRAS without defining an “allocation.” In casual conversation, the term allocation can refer to different concepts, so we must define it clearly for the purposes of this document.
In XRAS, an allocation is defined as an amount of consumable units on (or approved access to) a specific resource for a defined time period bounded by start and end dates. XRAS allows you to track the amounts requested by users, recommended by reviewers, and awarded by your site for every allocation.
Significantly, XRAS does not allow allocations for the same resource on the same project to overlap in time. Such allocations may be contiguous or have gaps, but they cannot overlap. The various transactions defined later in this section can be used to manage most scenarios without the need for overlapping allocations.
Requests
The allocations process model embodied within XRAS revolves around the notion of “requests.” A request is a fully detailed submission to be reviewed and processed to initiate or re-initiate an allocation or set of allocations. In most cases, you can think of a request in its non-technical sense: a person is asking for an allocation or allocations for their project.
XRAS recognizes two types of allocation requests: new and renewal. A new request will cause a new project to be created and indicates that there is no prior history to the proposed line of work. A renewal can only be submitted for an existing project. A renewal typically requires the same or similar detail as a new request and is intended to create a fresh set of allocations (i.e., covering a new time period) that begin after the current or prior set of allocations associated with the project. You can customize XRAS rules to define when new and renewal requests are permissible.
Project Management Actions
While the allocations awarded to a project as the result of processing a new or renewal request are active, XRAS supports a range of “actions” that can be used to manage or modify the active allocations for a project.
As an administrator, you can specify which actions are permitted during your organization’s resource allocations, when they happen, and which rules apply to each of them. If your process needs an action that doesn’t already exist in XRAS, you can request a new action type by contacting the XRAS team via allocations@access-ci.org. XRAS currently supports seven defined actions:
Extension. An extension will move the end date for all of a project’s current allocations on active resources. No additional allocation amounts can be added as part of an extension.
Supplement. With a supplement, a user can ask for additional allocation amounts to be added to all or some of their current allocations. A supplement does not change the end dates for any allocation.
Appeal. An appeal is a special case of a supplement that allows a user to contest the results of an allocation decision, often by correcting a reviewers’ misinterpretation or by providing missing details requested by the reviewer. XRAS allows you to define a window during which appeals may be submitted (e.g., within 30 days of an award being made).
Transfer. Within a given project, a user can ask for resource units to be moved from one allocation to another. Typically, some amount is subtracted from one allocation and added to another allocation.
Advance. Another special case of a supplement, in which additional allocation amounts are sought immediately, in anticipation of a future allocation award. Typically, the approved advance is added to a current allocation. Later, when the future allocation is made, it is reduced by all or some of the advanced amount.
Adjustment. An adjustment may be entered by XRAS admins to make changes to a project’s allocations, for any reason, usually to accommodate unusual situations that may arise. Users cannot request adjustments via the XRAS Submit UI.
Progress Report. This action allows a user to submit a statement of progress on a project. A progress report requires no processing and does not affect a project’s allocations. Note that a progress report document can be required as part of other actions.
Final Report. This action allows a user to formally close out a project by attaching a final report without asking for any additional allocations. This allows you to capture outcomes from users who have completed a project but who are not planning to submit a renewal request for that line of work.
XRAS allows you to configure rules to control if and when users are allowed to submit the different actions. For example, you may not want to allow a transfer to be requested within one week of a project’s current allocations ending. You can control if and when actions are permitted based on the dates and the status of their original allocation requests.
Users and Roles
The persons involved with an allocation request play a key part in the process. XRAS has a number of roles for persons who can view and edit a request, as well as additional individuals whose names may be part of the request’s data fields.
For the most part, XRAS is concerned with individuals insofar as they are assigned one of three specific roles associated with allocation requests. Once a person is added to a request in any of these roles, the request will be visible to (and modifiable by, per your rules) that person when they authenticate to XRAS Submit. Below, the role name used by ACCESS is presented first; alternate names are shown in parentheses. You can customize the visible role names using the XRAS Client Settings.
Principal Investigator, or PI (Project Lead). This individual has primary responsibility for the submission and ultimate use of any allocation awards. A request must have one and only one PI. Note that the PI on an allocation request need not be the PI on any supporting grant.
Allocation Manager (Project Admin). A request may have zero or more Allocation Managers; you can configure the maximum number of Allocation Managers allowed. Allocation Managers submit actions against that request.
Co-PI. A request may have zero or more Co-PIs; you can configure the maximum number of Co-PIs allowed. Co-PIs on a request can submit transactions against that request. Within XRAS, Co-PIs and Allocation Managers are functionally the same; however, these roles may be used to designate different levels of policy or intellectual responsibility for allocated projects within your process or local systems.
Note that the person submitting an allocation request is automatically added as an Allocation Manager on that request. If the submitter removes themselves (or is removed by another person) from that role and is not given another role, they will no longer be able to view or edit the submission.
Besides the designated roles above, the following individuals can be associated with various request fields. However, these individuals will not be able to view or edit the request.
Supporting Grant PI. The PI for each supporting grant is entered into free-text fields along with their email address. These fields can be used in XRAS email notifications about the request.
Program Officer. The Program Officer for each supporting grant is entered into free-text fields, along with their email address. These fields can be used in XRAS email notifications about the request.
Collaborators. A free-text Collaborators field allows submitters to enter any number of individuals who might be associated with the request in some way. This information is visible to XRAS admins and reviewers and can be used for determining possible conflicts of interest, for example.
User. XRAS allows a New or Renewal submission to indicate if other individuals should be given standard user accounts on allocated resources. The user information is passed to your site’s local accounting system along with the allocation award information. These users cannot view, edit, or submit actions for the project in XRAS.
Opportunities
The notion of “opportunity” helps organize the XRAS workflow and can generally be thought of as “a chance to submit requests of a certain type.” The types are defined by your allocations policies and entered into XRAS as part of your initial configuration. Each opportunity requires an associated “panel” to review the requests, although the panel may be composed only of you and your allocations staff. XRAS also supports multi-phase review processes involving more than one panel.
Opportunities come in two flavors: terminating and continuous. Terminating opportunities have fixed submission deadlines and are typically associated with larger-scale requests that are sent to a review panel and meeting. Continuous opportunities allow users to submit requests at any time, and incoming requests are typically reviewed and processed as they arrive.