See llms.txt for all machine-readable content.

Back to Templates

Route Synap marking and moderation requests to reviewers in Slack

Created by

Created by: Synap || synap
Synap

Last update

Last update 9 hours ago

Categories

Quick overview

For certification and assessment teams using Synap and Slack. Reviewers acknowledge or decline marking requests with emoji; the coordinator receives overdue, declined or conflicting work. The workflow keeps requests current as Synap changes and closes them when reviews finish.

How it works

  1. Every 15 minutes, read attempt-based marking sessions for the configured reviewers on one Synap exam.
  2. Create or load the queue table and compare current sessions with saved requests.
  3. Post new requests, refresh changed work and replace requests after reassignment or reopening.
  4. Send a threaded coordinator notice when work is declined, conflicting or overdue. Pause locked or suspended work.
  5. Every 15 minutes, check eyes/no_entry reactions only on tracked messages. Count only the mapped reviewer’s response.
  6. Recheck the current assignment in Synap, save the first valid response, and update Slack. Completed reviews close the request.

Setup

  1. Create a Synap PAT under Settings > Automations > API. Its user must be allowed to read all mapped reviewers. Save it as HTTP Bearer Auth and select it on both Synap GET nodes.
  2. Use a Slack bot with chat:write and reactions:read. Invite it to the channel and select its Slack API credential on all seven Slack HTTP nodes.
  3. Open Configure coordinator and set the portal ID, exam ID, API base, portal URL, channel ID, coordinator member ID and reviewerMap. Map Synap IDs to Slack member IDs.
  4. Choose a unique tableName for this exam. The node’s Settings > Notes contains a field guide, deadlines, limits and recovery steps. Review schedules against your n8n execution allowance.
  5. Keep the workflow unpublished while testing. Run Test a review poll first, repeat it to check duplicates, then react as the mapped reviewer and run the response check. Complete the review in Synap and confirm that Slack closes it.

Requirements

  • Synap v3 API access with permission to view each mapped reviewer’s sessions; a Slack bot with chat:write and reactions:read in the destination channel; and n8n with Data Tables. Tested on n8n 2.45.6 using built-in nodes.

Customization

  • Defaults allow three hours to acknowledge and 24 hours to finish. Both schedules run every 15 minutes: 5,760 scheduled executions per 30 days, including empty checks. Each run handles up to 50 changes or response checks, with a 500-session/row limit. A full sweep of 500 pending responses can take about 150 minutes. Set schedules and deadlines to fit your queue and execution allowance. The repeat interval is eight hours, with three notices per assignment cycle.

Additional info

Only mapped reviewers on one exam are included. Unassigned work, question-based marking and proctoring reviews are outside scope. Synap controls marking and result release; this workflow makes only GET requests to Synap. Candidate names, answers and scores are excluded from Slack and queue rows. API payloads may still contain personal data, so review instance logging and retention. Saved execution payloads are disabled in the export.

Use one active copy per exam/table and avoid overlapping source polls. If a Slack post times out or its table write fails, inspect the channel for the reference key before retrying. Slack and Data Tables are separate operations, so an uncertain send can duplicate on retry. Full setup and recovery steps are in Configure coordinator > Settings > Notes.