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 recurring allocations requests by the same lead investigator). The linkages provided by via 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.

...

It would be difficult to have any discussion about XRAS without defining an “allocation.” In casual conversation, the term allocation “allocation” can refer to different concepts, so we must define it clearly for the purposes of this document.

...

• 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 are 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.

...

• 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 can submit actions against that requestmanagement actions on behalf of the project.

• 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 requestmanagement actions on behalf of the project. 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 submissionproject’s requests or management actions.

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 new or Renewal 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.

...

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.