🏔️ Summit 2026 Feature
Send submitted form responses through a Reader workflow so reviewers can evaluate repeated requests, updates, and other form-driven work independently.
🏗️ Provisional document
This feature is pending release, and this document may change over time. Check What’s New for the latest releases.
Form response workflows let administrators build a workflow on a Form Response base. Each submitted response can move through its own workflow process, even when multiple responses belong to the same person, application, dataset record, or other record.
You can use form response workflows when review belongs to the submitted response instead of only to the underlying record. For example, a student might submit more than one change of major request over time. A form response workflow can route each request into Reader as a separate workflow record, preserving the review history for each submitted response.
Examples
Use a form response workflow when the submitted response should carry its own review status, assignment, communication history, and audit trail.
You might use a form response workflow to:
Route portfolio revisions, scholarship review forms, financial aid appeals, or department-review requests through separate workflow items. Each submitted response can be reviewed, assigned, and completed without replacing a previous response from the same applicant or application.
Route early alerts, change of major requests, course withdrawal requests, or other case-management forms through a response-based workflow. A student can have more than one active or historical request, and each submitted response keeps its own status and review path.
Route donor meeting requests, volunteer interest forms, research requests, or internal gift-processing questions through a workflow. Staff can assign follow-up and track each submitted response independently from the constituent record.
They can also be useful for:
Internal request queues
Use a form response workflow for administrative intake such as:
Marketing requests
Slate access requests
Query-update requests
Project requests
Admin-help forms
The submitted response becomes the unit of work, so teams can triage, assign, communicate, and close the request without building a separate custom portal or dataset queue.
Departmental requests for people outside the funnel
A college or department might submit a tour, visit, or service request for someone who is not a prospect. The workflow can track the submitted response as the review item without forcing the process to center on a person record that does not represent the work.
Post-review automation
After reviewers complete a response, workflow rules can support downstream work such as updating a status, creating the next review task, generating a letter, or sending a form-triggered communication. This keeps the automation tied to the response that was reviewed.
Audit and reporting
Because each response moves through Reader as its own workflow item, reporting can focus on response-level details such as submission date, current workflow position, assignment, completion, and related workflow history.
Before you begin
Create the form that will collect the response.
Decide which submitted responses should enter the workflow and which bin should receive them.
Plan the view columns reviewers need to identify and triage each response.
Create or identify the custom permission that should control Reader access to the workflow.
For workflow planning and configurations, see Workflows Overview.
Creating a form response workflow
Go to Database → Workflows.
Select New Workflow.
Configure the following settings:
Status: Active
Name: Enter a clear workflow name.
Type: Configurable Joins
Category: Related
Base: Form Response
Base Type: Specific form, event, or template
Folder: Select the folder that contains the form, event, or template.
Form/Event: Select the form, event, or template whose responses should move through this workflow.
Custom Permission: Select the permission that should control access to the workflow in Reader.
Select Save.
Adding workflow bins
Create at least one bin before routing responses into the workflow. The bin gives the form submission rule a destination for each matching response.
Open the form response workflow.
Open the workflow bins.
Use the existing default group, or create the grouping structure needed for the review process.
Drag a Column from the palette into the workflow group.
Enter the column name and select Save.
Drag a Bin from the palette into the column.
Enter the bin name, configure any needed bin settings, and select Save.
📖 Learn more about planning workflow bins
Moving submitted responses into the workflow
📝 Note
Form response workflows receive records through form submission rules. Create and test the submission rule before expecting responses to appear in Reader.
Build the rule from the workflow automation area, then set the action to move the submitted response into the appropriate bin.
Open the form response workflow.
Open the workflow's bin and queue automations.
Select New Rule.
Configure the following settings:
Name: Enter a clear rule name.
Rule Type: Bin
Rule Trigger: Form Submission/Update
Status: Start with Preview or Inactive while you build the rule.
Select Save.
Add filters that identify the submitted responses that should enter the workflow.
Configure the rule action:
Workflow: Select the form response workflow.
Bin: Select the bin where matching responses should enter the workflow.
Queue Action: Select a queue action when the response should be assigned to one or more readers.
Add Reader: Select a reader when the rule should assign the response to a specific user.
Select Save.
When you are ready to test routing, edit the rule details and change the status to Active. The Active status may not appear until after the rule has been saved.
Submit or update a test response and confirm that the rule moves the response into the workflow bin.
If the workflow is not ready for ongoing routing, return the rule to Preview or Inactive after testing.
Configuring the default Reader view
Create a default view so reviewers can identify each response in Reader. Because a form response may not have a helpful display name on its own, include exports from the form response base and the selected form. For example, a change of major workflow might include the submitted major request and workflow timestamp.
Open the form response workflow.
Open the workflow views.
Create or edit the default view.
Enter a view name and set the view status to Active.
Select Use this view as the default for all users for this base when this view should be the default Reader view.
Add exports for the response details reviewers need to see in Reader, such as the workflow timestamp.
Add exports from the selected form when the view should show submitted form values.
If the Configure Parts popup appears, select the generated join for the selected form and save the configuration.
Add filters or sorts only when they should apply to the view for all users who can access it.
Select Save.
Testing the workflow
Confirm that the workflow is active.
Confirm that the workflow has an active bin rule that uses the Form Submission/Update trigger.
Submit or update a test response for the selected form.
Go to Reader and open the form response workflow.
Use Search, Queue, or Browse to confirm that the response appears in the expected bin or queue.
If the response does not appear, check the rule status, trigger, filters, matching rows, bin action, and Reader access permission. Also confirm that the test response was submitted or updated after the rule was active.
Reviewing responses in Reader
Go to Reader.
Open the form response workflow.
Use Browse, Search, or Queue to find the submitted responses that need review.
Select a response to review the configured Reader tabs, form details, related record data, and review forms.
Move the response through the workflow according to your review process.
