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

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:

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. 

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 project’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.

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 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 reviewed and processed as they arrive.