For creators
Whiteboard edit access — students request, you approve
Students see your boards read-only by default. A 'Request edit access' button on the board page pings you in the notification bell; you approve from a dropdown on the same board. Approved students can edit alongside you; the rest just watch.
Last updated May 22, 2026
The student's side
When a student opens one of your public whiteboards from /p/<tenant>/my/whiteboards/<id>, they see the canvas in read-only mode with a 'Request edit access' button in the top-right. Clicking it does two things:
- Drops a request row into the workspace's pending-requests list.
- Fires an in-app notification to you — title is 'NameStudent wants to edit "BoardTitle"', body invites you to approve or deny.
From then on the request button on their side flips to 'Edit request pending' so they can't pile on duplicate notifications.
Your side
When a request is open, the board editor at /dashboard/whiteboards/<id> shows an 'Edit requests' button in the top bar with the pending count. Click it for a dropdown listing each pending student + Approve / Deny buttons.
- Approve → the student is added to the board's invitedUserIds. Their next render drops readOnly and they can draw alongside you. We also fire them an in-app notification ('You can now edit "BoardTitle"').
- Deny → the request is marked declined. We notify the student ('Edit access denied — the instructor kept the board read-only.'). The board stays untouched.
Why not just make boards public-editable
Two reasons. First, public-editable whiteboards become free-for-alls once a class gets large — someone always nukes the canvas by accident. Second, the request flow doubles as engagement signal: students who ask to edit are leaning in, and you'd usually rather know which students those are than blanket-grant everyone.
Related