RISE360 Collaboration Workflow

Lessons learned from working with clients in Articulate RISE360, establishing it as the single source of truth for course feedback and collaboration.

The Core Problem

When feedback flows across multiple channels — email, Word documents, and RISE360 comments simultaneously — it creates version confusion, missed edits, and unresolved comments that no one owns. The fix is consolidating everything into RISE360 and getting client access configured correctly from the start.

Access: Collaborator/Editor vs. Review-Only

This is the most common setup mistake. There are two distinct ways to share a RISE360 course with a client:

Review 360 (avoid for licensed clients)
- Sends an email link; the recipient views the course as an external reviewer
- Does not appear in the client's RISE360 dashboard
- Appropriate for stakeholders who do not have an Articulate license
- Comments are visible but the experience is disconnected from the client's workspace

RISE360 Collaborator/Editor (preferred)
- Add the client via the ... menu → Share → Collaborators on the course card
- The course appears in the client's RISE360 team folder
- Client can comment, view, and (if set to Editor) make direct edits
- Comments resolve and track within the same environment the team is building in

Observed failure mode: Sharing via "Request Review" in Review 360 sent email notifications but the modules never appeared in the client's RISE360 dashboard. The client was unknowingly reviewing an August version while the team was working on an October rebuild. Switching to Collaborator access resolved this immediately.

Version Visibility

RISE360 does not automatically push updated published versions to review links. If a module has been significantly revised:

Re-publish the module from RISE360 (this creates a new published version)
Confirm the client can see the updated version by checking the timestamp shown in their view
If the client reports seeing old content, re-publishing is usually the fix — not re-sharing

A client seeing a version dated months earlier while the team sees a current version is a strong signal that the review link was never updated after a rebuild.

Comment Resolution Workflow

Unresolved comments accumulate quickly when feedback comes from multiple sources. Establish this convention:

All feedback goes into RISE360 comments — not email, not Word docs, not Slack
When a comment is addressed, the person who made the change checks the Resolve checkbox in the comment panel
The original commenter verifies the change and confirms resolution (or re-opens with follow-up)
Comments from prior channels (Word docs, email) should be back-ported into RISE360 and resolved there so the platform reflects the true state of the course

Practical note: If a team member addressed comments from a Word document but didn't resolve them in RISE360, those comments remain open and create confusion about what's actually done. Resolve in the platform, always.

Navigating Comments in RISE360

To review all comments on a module without scrolling through the course:

Open the module in edit mode
Click the Feedback panel (comment bubble icon)
This lists all open comments with inline navigation — clicking a comment jumps to the relevant lesson block

This is significantly faster than scrolling through a long module looking for comment indicators.

Recommended Setup Checklist

When onboarding a client into a RISE360 project:

[ ] Add client as Collaborator (Editor) on all modules via the course card menu
[ ] Confirm modules appear in the client's RISE360 team folder (not just via email link)
[ ] Establish RISE360 as the only feedback channel — communicate this explicitly
[ ] Publish each module to make it reviewable; re-publish after major revisions
[ ] Agree on comment resolution convention (who resolves, when)
[ ] Schedule regular sync calls to walk through open comments together

Content Distribution as a Quality Signal

Maintaining a balanced mix of content block types signals intentional instructional design rather than a default-heavy build. A useful benchmark observed in practice:

~60% standard content blocks (text, statements)
Remainder distributed across knowledge checks, interactive tabs, and accordions
Avoid over-indexing on any single interactive type — it feels gimmicky; too few feels passive

Track block type counts across modules to keep the distribution intentional.

^[1]
^[2]
^[3]