Collaboration and watching¶

Risk work is rarely completed by one person. RiskVault keeps discussion, mentions, update subscriptions, and record-specific access beside the risk so people can work together without losing the decision trail.

Comments and threaded replies¶

Use comments for discussion that should remain part of the risk record: questions for the owner, review observations, evidence requests, and follow-up decisions.

Add a comment¶

1. Open the risk's Details page.
2. Scroll to Comments or follow a notification link that opens the comments section.
3. Write the comment. Include enough context for someone reading it later.
4. Mention a person when you need their attention.
5. Select the post action.
6. Confirm the comment appears with your name and time.

Reply in a thread¶

1. Find the comment you are answering.
2. Select Reply.
3. Write the response and add any needed mention.
4. Post the reply.

Replies stay grouped with the original comment, which makes a focused conversation easier to follow than a series of unrelated top-level comments.

Image needed: Risk Comments panel showing a top-level comment, a threaded reply, the Reply action, and the comment entry box with fictional content.

Delete or restore a comment¶

You can delete your own comment when the risk's comment permissions allow it. A user with comment-moderation access can delete or restore other comments. Deletion and restoration are controlled actions; do not use them merely to correct a small typo when a follow-up clarification would preserve useful context.

If the comment box or an action is missing, you may be able to view the risk without the permission to comment on it or moderate its comments.

Mention another user¶

Mentions notify a person and give them a direct path back to the relevant risk.

1. In a mention-enabled text box, type @ and begin the person's name.
2. Wait for the autocomplete list.
3. Select the correct person rather than typing a name as plain text.
4. Finish the message or notes.
5. Post the comment, save the section, or complete the workflow action.

RiskVault supports mentions in more places than the Comments panel, including:

• workflow transition comments;
• rejection and on-hold reasons;
• tolerance justification;
• treatment plans and action plans;
• effectiveness-review notes;
• resolution notes.

The selected mention is stored as a stable user reference and displayed by name. Older email-style mentions remain readable. RiskVault safely formats mention text and does not treat it as executable page content.

What the mentioned person receives¶

Subject to their notification preferences, a mentioned person can receive:

• an in-application notification;
• a real-time notification-bell update;
• an email notification;
• a link to the relevant risk or section when one is available.

RiskVault does not notify you for mentioning yourself. Multiple mentions created by one workflow transition can be grouped so the recipient understands where the mentions came from.

Mentions do not grant access. If the person cannot view the risk, the mention is not a substitute for a permission grant. Arrange the appropriate access separately.

Watch a risk¶

Watching is useful when you care about a risk but are not its owner, reviewer, or another stakeholder who already receives role-based notifications.

Start or stop watching¶

1. Open the risk's Details or Edit page.
2. Select the eye-shaped Watch control. The same action may also appear in the overflow menu.
3. Confirm that the control changes to Watching.
4. Open Risk Register > Watched to confirm the risk is listed.

To stop, select Unwatch. RiskVault does not automatically unwatch a risk when it closes or is archived; this allows you to receive later reopening or audit follow-up updates.

Image needed: Risk header with the Watch/Watching eye control and overflow-menu action, plus a small inset of the Watched Risk Register view.

Why the Watch control may be hidden¶

Creators, owners, identified-by users, reviewers, action owners, and designated approvers already receive notifications through their responsibility. RiskVault can hide Watch for these implicit stakeholders to avoid duplicate subscriptions.

You must also be allowed to view the risk. If your view access is later removed, RiskVault silently stops sending watched-risk information even if the stored watch remains.

Updates that can notify watchers¶

Watched-risk notifications can cover:

• workflow state transitions;
• approvals, rejection, and requests for more information;
• new comments and replies;
• changes to important assignments;
• due-date and treatment-date changes;
• treatment plan, on-hold reason, effectiveness notes, rejection reason, and tolerance justification changes;
• action-plan, root-cause, and sensitivity changes.

If you become a direct stakeholder after watching, notification deduplication prevents the same event from being sent twice.

Set watched-risk preferences¶

1. Open My Account > Notification Preferences.
2. Find watched-risk updates.
3. Enable or disable the available in-app and email delivery options.
4. Save your preferences.
5. Use the Watched register view to manage the risks you follow.

Stopping email delivery does not necessarily remove the watch; use Unwatch when you no longer want the subscription at all.

Who can see a risk¶

Risks are open to everyone in your organization by default: any signed-in user can find and read a risk unless it is marked sensitive or restricted to a department. Drafts are the exception; only the creator can see a draft until it is submitted.

• Sensitive risks are visible only to people with the permission to view confidential risks.
• Department-restricted risks are visible only to members of that department, people with department access to it, and people who can view all risks. Viewing all risks doesn't open sensitive risks; that still needs the confidential permission.

Some people can see a risk whatever its restrictions:

• The people assigned to it. The risk owner, action owner, reviewer, treatment approver, and tolerance approver can always open it. The owner can do everything on it; the others can read, comment on, and edit it until it is closed or archived. This access follows the assignment: when someone is replaced, the new person gains it and the previous person loses it.
• Anyone given a per-risk grant (see below).
• The creator, who can still read and comment on the risk after submitting it, unless it is sensitive.

Reading a risk isn't the same as working on it. Editing, deleting, commenting, and every workflow step still need the matching permission.

Give someone access to one risk¶

Per-risk permissions let a specific person, role, or department work on one record without receiving broad access. Manage them from the Permissions panel on the risk's Details page.

Who can grant. You need the Manage Permissions grant on that risk, or the Risk.AssignOwner claim. A risk's owner can always manage its permissions.

Who you can grant to. A single user, everyone in a role, or everyone in a department (business unit).

What you can grant. Each grant covers this one risk only, and any grant also lets the person open and read the risk, including its comments and attachments.

Permission	What it allows on this risk
View	Open and read the risk, its comments, and attachments.
Edit	Open the edit view and add or remove attachments and links. Which fields they can change still depends on their claims and the current workflow step. Edit grants are removed automatically when the risk is closed or archived.
Comment	Add comments and reply to them.
Delete	Soft-delete the risk (still blocked by a legal hold or the retention period).
Restore	Bring the risk back after it was deleted.
Moderate Comments	Delete or restore other people's comments on this risk, including ones that already have replies.
Manage Permissions	Grant and remove these permissions for others on this risk.

Add a permission grant¶

1. Open the risk's Details page and find the Permissions panel.
2. Choose whether to grant access to a user, role, or department.
3. Search for and select the intended recipient.
4. Select only the permissions needed for the task.
5. Optionally set an Expires date.
6. Save the grant.
7. Ask the recipient to confirm access with their normal account.

Image needed: Permissions panel on Details showing the User/Role/Department selector, permission checkboxes, Expires date, and a grant marked “Through” a date.

Make a grant temporary¶

An Expires date makes a grant stop applying on its own, so nobody has to remember to remove it. The grant works through the end of that day in your own time zone. The date must be after today; leave it empty for a grant that never expires.

The permissions list shows each grant's expiry in your local time as “Through date” or “Never.” An expired grant stays in the list, marked “Expired date,” so you can see what was granted and remove it, but it no longer gives any access. To extend or remove an expiry, grant the same permission again with the new date, or with no date.

People assigned to the risk¶

The risk owner, action owner, reviewer, and treatment and tolerance approvers get the access their assignment needs automatically; they don't need a grant. Because a grant is independent of the assignment, a grant you gave someone stays in place when they stop being assigned.

Remove access¶

1. Return to the Permissions panel.
2. Locate the user, role, or department.
3. Confirm no active responsibility still depends on it.
4. Remove it. This removes every permission you granted them on that risk.
5. For sensitive access, verify that it is no longer effective.

Removing a grant doesn't affect access someone has through their claims or an assignment.

Collaboration history and good practice¶

Workflow history records state changes and their associated notes. Activity and audit records capture other significant actions. When an update seems unfamiliar, review the history before assuming another user made it; workflow rules and connected systems can also update a risk, and their activity is recorded.

For useful, readable collaboration:

• keep one topic in one comment thread;
• mention someone only when action or awareness is genuinely needed;
• put formal treatment and decision content in its proper workflow field, not only in a comment;
• avoid copying secrets or unnecessary personal data into comments;
• use per-risk grants instead of broad roles for one-off participation;
• unwatch records you no longer need to monitor.

Troubleshooting collaboration¶

The person I mentioned received nothing

Confirm you selected them from autocomplete, saved or posted the text, and they can view the risk. Ask them to review notification preferences.

I cannot comment or reply

Check your per-risk comment capabilities and the record's state. View access alone is not always enough.

Watch is missing

You may already be an implicit stakeholder, lack view access, or be viewing an ineligible record.

A watched update did not arrive

Confirm the watch still appears, watched-risk notifications are enabled, and you still have view access. Not every minor field edit generates a watcher notification.

For attachments, tags, Jira, and related-risk links, continue to Files, links, and tags.