Understand the outcome
Channel access is worked out from roles on every request, so role choices matter.
Chat is department messaging organized into channels. Administrators create channels for a shift, station, committee, or the whole department and choose which roles can read and which can post. Members reply, react, mention colleagues, and share photos and files. New messages reach phones as push notifications through the Station Clipboard mobile app, tuned per channel. Chat replaced the conversation part of the retired Spaces module.
This guide focuses specifically on “Create a chat channel and set role access.” Complete it from an account with the appropriate Chat access, verify it from the affected member or operational view, and preserve existing records rather than repurposing historical configuration.
Before you begin
Make the decision before changing the screen. Record the current configuration when the department already uses this feature, and use a test record or test account when the change can affect active members.
- Decide the channel’s purpose and audience.
- Decide whether it is read-only for most members.
- Pick a default notification level.
Do not work around it from another member’s account. Confirm that Chat is enabled, its dependencies are active, and your role grants the exact management action required for this task.
Where to work and what access you need
Start from the portal destination named in the procedure. Administrators normally need permission to view Chat plus the specific create, edit, manage, approve, report, or all-record action used by the task. Visibility alone does not grant management access.
- Chat
/modules/chat - Channel
/modules/chat/:channelId
Required foundation
- Core must be enabled and correctly configured before this workflow can operate reliably.
If your department uses custom roles, test the procedure with that role—not only with a full administrator account. This confirms the people responsible for daily operations can complete the workflow without receiving unrelated access.
Complete the task
- Step 1Create the channel
Open Chat and create a channel with a name, emoji, and topic.
- Step 2Set read roles
Choose the roles that can read it.
- Step 3Set post roles
Choose the roles that can post; leave others read-only.
- Step 4Set uploads and notifications
Allow or block uploads and choose the default notification level.
- Step 5Test
Check access from a member account.
- Step 6Moderate
Pin key messages, remove messages when needed, and archive the channel when it is done.
Operational safeguards
Apply these module-level controls while completing the procedure. They prevent a technically saved configuration from becoming an operational or access problem later.
- Control point
Plan a small set of channels before launch. - Control point
Use read-only channels for announcements that should not collect replies. - Control point
Set post roles carefully for department-wide channels. - Control point
Choose sensible default notification levels. - Control point
Tell members to install the mobile app and allow notifications if they want push. - Control point
Archive stale channels instead of leaving them open.
Verify the result
Do not consider the setup complete merely because the save action succeeded. Confirm the behavior from the user-facing or operational view, then retain evidence of the test when department policy requires it.
- Intended members see the channel.
- Read-only members can’t post.
- Others can’t find it.
If any verification fails, return to the source configuration and correct it there. Do not edit a report or downstream record to conceal an incorrect setup.
Troubleshooting
A member can’t see the channel
None of their roles is a read role.
A member can read but not post
Add one of their roles to the post roles.
@everyone doesn’t work for someone
It is limited to moderators.
Connected modules and downstream effects
A change here can alter what members see, what data appears in reports, or how another module completes its workflow. Review the connected areas below before making a department-wide change.
- MeetIn-portal video meetings with role invites, host controls, and attendance.
- TicketsDepartment requests routed by category and role, with SLA due dates.
After deployment, test one complete workflow from the originating module through every connected destination your department uses. Document the final configuration so another administrator can audit or reproduce it later.
Continue in Chat
Return to the Chat module guide for connected workflows, dependencies, portal destinations, and additional procedures.