The following configuration features are accessed via the XRAS Admin settings menu—the gear icon on the top navigation bar. The gear icon menu is also where you’ll find Client Settings; those settings are generally required to begin using XRAS and are discussed as part of the Initial Setup and Customization.

Default Reviewers

If you wish to have “Default Reviewers” for any of your panels, you can select the Default Reviewers option under the settings menu to get a system-wide summary of all such reviewers across all of your panels and allocation types. You can configure XRAS to assign the same default reviewer to every submission to an opportunity, or you can have XRAS assign a default reviewer based on the resource(s) requested in each submission. With a resource-based assignment, a submission that asks for multiple resources will have the default reviewer for each resource assigned to review the request. You can also specify default reviewers for specific action types (new, renewal, supplement, etc.)

Under the “By Panel” tab, you will see your default reviewers sorted according to your various panels. Here, if you click on the panel name, you will be taken to the “Current Members” tab for that panel. And if you click on “Edit Default Reviewers” (at right), you will be taken to the “Default Reviewers” tab for that panel.

Under the “By Allocation Type” tab, you will see your default reviewers sorted according to allocation type. Note that the By Panel and By Allocation Type lists will be very similar if you have only a single panel associated with each allocation type.

Notifications

Notifications are email messages that are sent to users or groups of users when specific events occur in XRAS. Such notifications help both administrators and users to track the state of requests within the allocations lifecycle. The “Notifications” interface allows you to tailor the email messages that XRAS sends. XRAS provides a great deal of flexibility in the email messages that the system sends, but it also requires some time and attention to properly configure XRAS to your site’s needs.

You must configure XRAS to send notifications when specific scenarios occur. These scenarios (or rules) are combinations of the available Allocation Types, Action Types, Event Types, and Recipient Types. 

Notification Templates

The initial screen includes a summary list of all available notification templates. You can filter the list (blue button) to zero in on a specific template or determine if a template already exists for a given scenario.

• Clicking anywhere in a row of the table will take you to the editing screen for that template.

• The “Copy” button in a row will create a copy of the email template and take you to the editing screen. The copy will be associated with no scenarios; you will have to assign scenarios on the editing screen (see below). 

• The trash can icon will delete the template, removing it and its associated scenarios.

Create/Edit Templates

To customize the email messages sent to users or other recipients, you can create a new template (green button above the list of Notification Templates) or edit an existing template (click the row for a current template or make a copy of a current template). All of these actions will take you to the create or edit template screen; both screens are organized identically.

Template

The Template section allows you to enter the various components of the email message to be sent, including the sender, fixed recipients, subject line and the body of the message. The fields of the template can include static text, and most fields can include Tags. When sending notifications, XRAS replaces each tag with the appropriate values from the submission that triggered the message to be sent. 

Available Tags

To the right of the Template section, XRAS displays the available tags. Notification tags are used in templates to tell XRAS to substitute submission-specific values into the final email messages, much like the mail merge function in word processing programs. Tags can be added to the subject, body, cc, and bcc fields of the message. The simplest way to insert a tag in the subject or body field is to place the cursor at the appropriate location and click on the desired tag from the Available Tags list. You can also type the pipe character— “|” — and a dropdown list of available tags will appear.

Only tags that represent valid email addresses, such as “|PROGRAMOFFICEREMAILS|”, can be added to the cc or bcc fields. You must either type in the entire tag value, or copy and paste the tag from the Available Tags list.

Rules

The Rules section (below the Template section) is where you define the scenarios in which the template will be used to send notifications. Click the “Add Rules” button to add a new rule. In the pop-up window, select one or more allocation type, action type, event type, and recipient type, then the “Add Rules” button. You can also delete a newly created or previously existing rule within the pop-up using the appropriate delete (trash can) button. In the Rules section, you can also delete an existing rule or rules directly. A note of caution: If you delete all the rules for a template and save, the template is effectively deleted.

When defining rules, the allocation types are the types you have defined for your allocation process, and the action types are the actions you have configured XRAS to support for your process (supplement, extension, and so on). The event types and recipient types are specific to the Notifications feature.

Event Type. The “Event Type” specifies different points in the submission, review, and processing workflow that can be used to trigger a message to be sent. XRAS currently supports sending notifications when the following events occur. Some events trigger a message automatically and some events require you to manually trigger the message, such as by clicking a button.

• Action Approved—when the status of the action is set to “Approved” by an admin (manual)

• Action Finalized/Submitted—when the status of the action is submitted (automatic)

• Action Rejected—when the status of the action is set to “Rejected” by an admin (manual)

• COI Reported—when a reviewer uses the Report COI feature within a request (automatic)

• Each Review Submitted—when individual reviews are completed for a request (automatic)

• Reviewer Assignments—when a reviewer is assigned to a request; the opportunity must be set to have reviewer assignments visible (automatic). Note: Does not apply to Default Reviewers.

• Reviews Completed—when all review assignments for a request have been completed (automatic)

Recipient Type. The “Recipient Type” allows you to tailor messages about events to different stakeholders in the allocations workflow. XRAS distinguishes the following recipients for the purposes of notification scenarios. Not all recipients may be available for every submission.

• Allocation Manager—the person(s) with this role on the request

• Allocation Process Manager—you, another XRAS admin, or other email address; you work with the XRAS team to set this email address 

• Co-PI—the person(s) with this role on the request

• NSF Program Officer—the program officer(s) associated with any NSF supporting grants on this request. (This will only apply to supporting grants that have an agency of “NSF” specified)

• PI—the person with this role on the request

• Reviewer—a member of a Panel assigned to review this request

• Service Provider—the person/group associated with a resource connected to this request

After adding rules, be sure to click the “Save” button to save your changes to the template and the rules. The “Cancel” button will exit the editing screen without making any changes. You must define at least one rule in order to retain and save a template.

Preview Notification. XRAS will let you preview the message a recipient will see, i.e., the message with the tags replaced by actual values. Click the “Preview Notification” button and a Notification Preview dialog box appears with a search box. You need to pick a sample request or action to use for the preview. Entering partial request numbers will work, and this search returns only projects that have applicable actions for the current notification. Select the action for which you want the preview, and XRAS will display a preview in a new browser tab. Close the dialog box to return to the template editing screen.

Reconcile Users

If you have opted to allow Guest Users to submit requests, you can later “reconcile” these guest users, once you have created their permanent local user account. Reconciling users allows the users to see their requests and reviews, and over time, ensures that a user’s entire history of requests is connected.

Select “Reconcile Users” from the gear menu to see the current list of unreconciled users, if any. For each user, click anywhere in the row to reconcile that user. The left side shows the information about the user from their XRAS submission. The right side has a search box for your identity service. Begin typing the user’s first or last name to bring up possible matches and select the correct match from the list.

XRAS will display the corresponding information from your identity service on the right. Select “Cancel” to choose a different user or select the “Reconcile User” button to update the XRAS submission with the official user information. That user can now log in with their permanent user account and see the submissions previously associated with the guest account.

Resources

To be included within allocation opportunties, resources must first be established in the Cyberinfrastructure Description Repository (CIDeR). See Appendix: Using CIDeR to Create Resources. Once defined in CIDeR, you manage the remaining XRAS configuration in XRAS Admin, by selecting the “Resources” option under the gear menu.

Select the blue “Add a Resource from CIDeR” button to add each allocable resource. From the pop-up dialog, select the resource you want to add. If you don’t see the desired resource, it’s most likely a configuration issue in CIDeR, so review the instructions in this guide’s appendix.

Once a resource has been added, it will appear in the Resources list. You can reorder the list by clicking and dragging the three-line icon to the left of the resource name. The order of the Resources list here does not currently have any effect outside of the Admin interface.

The Resources list has tabs that separate Active from Inactive resources. A resource becomes Inactive if it has been added to your allocations process and if the resource is set as “Unavailable” for all allocation types it has been part of (see below).

To configure a resource, click on the resource name in the Resources list. The resource screen is divided into three sets of configurable options.

Resource Properties

Note that these resource properties are global settings and will affect how the resource is displayed in all allocations processes that include the same resource.

• Resource Name. By default, this is the name given the resource in CIDeR. You can edit this value to display a different name in the submission interface.

• Resource Repository Key. Cannot be edited. Defined in CIDeR.

• Dollar Value per SUs. (optional) You can enter a dollar value for the allocable unit (a.k.a., Service Unit, or SU) for the resource. While not displayed in most XRAS interfaces, this value can be used in XRAS reports and notifications, e.g., to show the total dollar value equivalent of allocations made on a resource, or to inform researchers of the dollar value equivalent of their allocations.

• Allocations Description. This text will appear below the resource name within the submission interface. Again, this appears in all allocation processes in which the resource appears.

• Resource Type. This defines the category for the resource and is used by XRAS in certain places to group resources.

• Unit Type. The allocable unit for the resource—that is, users will ask for amounts of this unit when requesting this resource. The unit label will be displayed in the submission UI, and this is a controlled vocabulary of unit labels. Core-hours and GPU-hours are probably the most commonly used, but you can contact the XRAS team if you need a different unit type for a particular resource. The special “Yes/No” unit type allows you to avoid asking users for a numeric value, and users will instead be asked simply to answer “Yes, I’d like to use this resource.”

Allocation Types

This section is key. Here is where you define which opportunities the resource will appear in, and for which kinds of requests and actions the resource will be available.

• First, select the “+ Add Allocation Type” button to link the resource to that type of opportunity.

• Then, select the Allowed Actions for that resource. By default, XRAS has several options here. These options are defined by the life cycle stage of a resource and the actions commonly permitted for that life cycle state. If these options are unsuitable for your allocations scenarios, you can contact the Allocations team for different combinations. To remove a resource from an allocation type, select “Unavailable.”

• Finally, you can add Descriptive Text specific to that allocation type in your allocations process. This text will appear in the submission interface. This allows you to tailor a brief message about the resource to the specific types of opportunities in your allocation process.

Add Required Resource. XRAS allows you to specify which resources must be allocated together with the “+ Add Required Resource” button. A common scenario is this: You have a computing resource to allocate, and every time you grant an allocation, you also want to allocate a user-requestable amount of space on an allocated storage resource.

For this scenario, both the computing resource and the storage resource must be created in CIDeR and added to your allocations process, and both resources must be added to the same allocation type. Then, to require a user request storage units when they ask for compute units, you will edit the compute resource and, in this section, select the “+ Add Required Resource” button and then select the storage resource from the list. Note that this resource relationship must be configured for each relevant allocation type.

Also, note that, in the scenario described, users could make standalone requests for the storage requests. If that is not desired, you should make the compute resource required when the storage resource is selected by the user.

Resource Submission Questions

XRAS also allows you to create a set of questions that users will answer when they select a specific resource. These questions will appear in every allocation type when the user selects the resource. If the resource is part of more than one allocation process, the questions will also appear in every allocations process.

Select the “+ Add a Question” button to define each question. The question building interface is the same as that used for adding custom Opportunity Questions. As you add each question, the table on this page will allow you to customize the order of questions and activate or deactivate a question.

Rules

As an XRAS admin, you can describe the allocation operations, definitions, and constraints or policies that apply to your organization by configuring “rules” that tailor how XRAS behaves in different situations. To ensure XRAS behaves as you expect, you are strongly encouraged to review all the rules settings before you start accepting submissions via XRAS. Many of the rules rely on or refer to values or controlled vocabularies you should have configured as part of your initial setup.

If the following rules options are not sufficient to match your organization’s allocation policies, requests to enhance the interface can be sent to allocations@access-ci.org and we will add them to the XRAS feature roadmap.

Rule: Ineligible PI/Project Leads. You can specify the types of persons who are ineligible to be PI/Project Lead on allocation requests. For example, you can declare graduate students to be ineligible to be PI/Project Lead on certain allocation types.

Rule: Maximum Requests per Allocation Type. You can restrict a user to a maximum number of requests of different allocation types. By default, XRAS will allow a user to submit an unlimited number of requests for each type. The maximum requests is the combined total number of active requests and submitted requests. For example, setting 2 maximum requests and 1 maximum active request allows a user to have 1 current award and 1 renewal request, but does not allow the user to submit a renewal for an opportunity that starts before their "active" award ends. 

Rule: Restrict Cross Type Submissions. You can prevent a user from submitting a request of one allocation type if they already have an awarded project of another allocation type. For example, a user who has an awarded project of Type A should not be allowed to submit a request for a project of Type B.

Rule: Request Action Time Periods. You can control when XRAS allows users to submit actions related to different allocation types. You can add, edit, delete, and view the time periods for actions. For example, you may only allow a renewal allocation request to be available within 30 days of the current request ending.

Rule: Required Submission Fields. You can define which fields are required for different actions for each of your allocation types, as well as customize the error message displayed if a required field is missing when a user tries to complete a submission.

Rule: Required/Optional Documents. You can define the types of documents required or allowed for the actions associated with different allocation types. You can also choose whether one or more than one of each document type should be allowed, and set page limits allowed for each document type. If no rule is defined for a particular document type and action, then that document type will not be available for that action in the default XRAS Submit UI.

Rule: Manage Invitations to Opportunities. XRAS allows you to declare some opportunities to be “invitation-only.” This rules interface allows you to manage the lists of invited users. In the “Invitations” section, enter either the first or last name of the user to be invited. From the search results, choose the desired name. Then, select the relevant opportunity from the drop-down list of all invitation-only opportunities, and click the “Add invitation” button. To un-invite the user, simply click on the “Delete” button for that entry.

Rule: Enable Public Request Pages. XRAS can provide a public information page for each of your awarded projects. These pages are created to show users’ awarded allocation resources. Here you can specify which allocation types have or may have public pages associated with them. You can choose (a) no public pages are created (Never), (b) public pages are automatically created for all approved requests (Always), or (c) public pages are only created for approved requests that are explicitly posted to ORCID (Only if posted).

Rule: Manage Actions for Resource States. XRAS can tailor what allocation actions are available for a given resource at different points in that resource’s lifecycle. For example, you might allow “new” requests for a pre-production resource, but not transfers or supplements. Similarly, when a resource is in post-production, you can stop accepting new requests but may choose to allow transfers of allocation units from that resource to other resources, by only permitting negative transfer amounts (i.e., transfers to reduce an allocation amount). The resource state is controlled via the Resources settings (see XRAS Admin: Settings).

Rule: Manage Allowed Allocation Type Transfers. If your allocation policies evolve over time and you add or remove allocation types, this rules page allows you to manage how researchers can transition projects from past allocation types to current allocation types. This rule is useful if you expect researchers' projects to persist over time and want to help them transition their projects to the new allocation types.

User Permissions

The User Permissions option provides you with a list of all persons who have been given permissions to use XRAS Admin for your allocation process. To revoke permissions for any person, use the “Revoke” butt at the right of the appropriate row.

While it’s often faster to use the search bar at the top of the XRAS Admin pages to find and grant permissions to individuals, you can also grant permissions from this page.