Permissions: Users must have the RBQM, Data Central, and View privileges assigned to a study to access RBQM and manage Issues in RBQM.
Issues are created manually from within RBQM or created automatically based on KRI and QTL configuration and the defined actions. Actions are triggered by the risk level of the KRI or QTL, and issues are created each time RBQM is run. During the configuration of RBQM, actions can be configured to trigger only when the KRI or QTL score differs from the previous score, shows a higher risk than the previous score, or remains the same as the previous score.
Users can easily view a filtered list of RBQM related issues by opening the Issues panel directly while working within RBQM, or they can view all RBQM issues by clicking the Issues tab on the RBQM header. When the Issues list opens, it floats in front of the current view.
Issues created in RBQM are added to the Global Issues list and have the same features and functionality as issues within Data Central and Global Issues.
Tip: To quickly access open Issues that are assigned to the user logged in, access Issues from the Platform Menu.
Create an Issue
The types of issues created in RBQM include Country, Study, or Site, and are determined by the dashboard, chart, or listing where the issue was added, or a cell on the Overview page. For example, creating an issue from a site-level chart or listing will have a Type = Site, or creating an issue from the Country map will have a Type = Country.
- Right-click any cell on the Overview page or drill down to the desired location to add the issue.
-
Click the Create Issue icon. The Create Issue window opens.
Tip: This window can be moved by dragging it elsewhere on the screen to view the window behind it.
Issue details are pre-populated in the top section of the window. Depending on where the issue was created, details may include Type (Country, Study, or Site), Site, Site ID, Country, Country ISO, KRI Name, and Score.
- Click the Priority drop-down arrow to select a different priority.
-
Select User, Role, or User Group in Assign To.
Note: Assignment can be to a specific user, role, or user group.
-
Click the User / Role / User Group drop-down arrow and select the appropriate user, role, or user group.
Note: Names that display in the Assign To User list include both licensed and unlicensed users.
- By default, the Due By date displayed is +1 day. Optionally, update the date by entering over the date displayed, or using the Calendar icon.
- Enter the Issue Text.
- Select the Send Notification to the User/User Group checkbox if appropriate. If the issue is assigned to an unlicensed elluminate user, be sure to check the box.
- By default, Send immediately is selected. Select Send in batch if a task to send Issue Notifications is scheduled. Select Defer Notification to delay the notification, sending it at a more convenient time using the Issues module.
- Select the Receive notifications for these changes checkbox if the creator of the issue would like to receive a notification when there are changes to priority, assignment, and status. By default, all three boxes are checked. Uncheck any boxes if users do not want to receive notifications.
- Click Save. The new issue is added to the Issues listing.
Manage Automatically Created Issues
Issues are created when an RBQM run occurs on scheduled intervals. Within RBQM configuration, actions are configured for issues assigned to a role, typically the Site Monitor, though a different role may be specified.
RBQM Issues assigned to the Site Monitor (or other role) are then reviewed, edited, and re-assigned to a specific user. An Issue can also be actioned (start progress, move to pending, answered, closed, closed as irresolvable, re-opened, or canceled) depending on the status of issue and user privileges.
Tip: Issues may also be managed from global Issues. Click the 9-dot icon in the master header to access Issues from the Platform Menu under Data Review. For more details on how to manage Issues see the global Issues section.
Edit an Issue
- From the Details View, click the Edit icon in the toolbar.
- Update the Priority from the drop-down list.
- Update who is assigned to the issue: Select the Assign To User / Role / User Group radio button.
- Update the user, role, or group: Click the User / Role / Group drop-down and select a user / role / group.
- The creator of the issue, or users that have the Issue Administration privilege, can:
- Update the Due By date.
- Update the Issue Text.
- Optionally, select the Send Notification Email checkbox.
- Click Save.
Snooze an Issue
When an issue is assigned to a user, they receive an email notification. This notification indicates the assignment and, depending on the notification settings, alerts them when the issue is overdue. To temporarily suspend work on an issue without closing it, users can snooze it. Once snoozed, no overdue notifications are sent until the defined 'Snooze Until' date. Furthermore, snoozing prevents the generation of additional issues based on the snoozed KRI or QTL action for the same site until that date passes.
Important: Snooze functionality only works with RBQM issues that were created automatically, or by the system; issues that are created manually cannot be snoozed.
Close & Snooze an Issue
- When updating the Action of an Issue to Close or Close as Irresolvable, check Snooze Issue.
- Update the Snooze Until date using the calendar picker, entering the date.
-
Click Yes.
Tip: The snooze option is available only when closing a single issue; it is unavailable when closing multiple issues from the Issues listing.
The Issue details are updated. Issues system generated by the RBQM Engine include the KRI Name, Score, and Risk Level. Notice the Snooze icon becomes active in the toolbar, and the Snooze Until date field is populated.
Update the Snooze Until Date
- From the Details View of a snoozed Issue, click the Snooze icon.
- Update the Snooze Until date.
- Click Save.
Remove the Snooze Until Date
- From the Details View of a snoozed Issue, click the Snooze icon.
- Click Delete.
Important: Even if a KRI or QTL is configured to trigger an issue only when there are data changes or increased risk, and the issue is snoozed, a reminder will still appear after the snooze period ends, regardless of whether the data have changed. This is because the snooze is a user-defined setting, while the trigger is a study configuration; therefore, the reminder reflects the user's snooze request.