A submission process tells Rhythm how one kind of submission works, including which web form a member fills out. Every submission type in a Portal-form space uses a process, so create the process before you offer that type to members. For the other process options, see Contact Details, Editing, and Confirmation Email for a Process.
Prerequisites
- You need access to the space's setup pages.
- A Submission web form should already exist in your Rhythm account for the process to use. See Configure Web Forms.
Where to Find It
Go to Spaces › (space) › Setup › Submissions › Processes to view the processes in that space. Select Create Submission Process to add a process, or select a process name to edit it. The list also shows each process's status and when it was last changed.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Name | Any text | — | Required; identifies the process for staff |
| ID | Generated from the name; letters, digits, underscore, colon, pipe, and hyphen only | Generated, prefixed with the space's identifier | Permanent identifier; cannot be changed after you save |
| Submission Form | One active Submission web form in your Rhythm account | — | Required; this is the form members fill out when they use the process |
| Status | Active / Inactive | Active | Controls whether members are offered types that use this process |
| Deletion Protection | On / off | Off | Visible to Rhythm staff only; when on, the process cannot be deleted |
Creating a Process
Give the process a name and choose the Submission Form it uses. You must choose a form before you can save because the page and the underlying rule both require it. A submission type's process choice is only labelled required. After you save the process, you can attach it to one or more submission types.
An abstract approval process also needs a form before you can save it, even when presenters have nothing extra to provide. If you have no additional information to collect, choose a form that is empty or contains only confirmation text.
Stopping a Process Without Deleting It
Set Status to Inactive to stop offering the process and every submission type that uses it, without deleting anything. This works differently from marking a submission type inactive. When a process is inactive, Rhythm removes it from the list of options members can use because that list drops any process whose status is exactly inactive. Existing submissions made through the process before you deactivated it are not affected.
If a space still has more than one active process, such as processes left over from an earlier year alongside the current one, the space can keep resolving to the wrong process or create a submission under the wrong year's process. Deactivate old processes you no longer need instead of leaving them active alongside newer ones.
Reordering Processes
The list includes a drag handle so you can place processes in a chosen order. However, the list loads in alphabetical order by name, so changes you make with the drag handle will not be visible the next time the list loads. If you need a specific order, rename the processes so their names sort that way.
Deleting a Process
You can delete a process only when no submission type and no submission names it. If either one does, Rhythm refuses the delete and keeps the process in place. Reassign or remove the dependent types and submissions first. Deleting a process with nothing depending on it does not delete its web form.
The same protection works in the other direction. A web form that a process uses, either as its submission form or as a separate editing form, cannot be deleted while that process exists. A space that still holds any type or process cannot be deleted either. If Rhythm refuses to delete a space, process, or web form, look for what still depends on it before trying again.
Permissions
Creating, changing, reordering, deactivating, and deleting submission processes requires the day-to-day or administrator access your organization grants for Submissions setup. You configure these settings in the Console. Members cannot change them in the Portal.
Dependencies and Precedence
- A type needs an active process to ever reach the Portal. See Submission Types.
- Deactivating cascades through every type that uses the process, because the type-offering rule checks the process's own status, not just the type's.
- Deleting is blocked by types, submissions, and — for the process's forms — deletion of the underlying web form.
Change Impact and How to Revert
Deactivating a process is reversible at any time. Switch Status back to Active to make the process, and the types that use it, available again. Changing the submission form on an existing process changes what the next submitter sees, but it does not alter submissions already made through the old form. There is no automatic revert for a deleted process. If you delete one in error, recreate it and reattach it to the types that used it.
Validation and Errors
| Message or behavior | Cause | Fix |
|---|---|---|
| Save refused, missing form | No Submission Form was chosen | Choose a Submission web form before saving |
| "Unable to delete Submission Process" | A submission type or submission still names this process | Reassign or remove the dependent type or submission, then delete the process |
| A web form will not delete | A submission process still uses it as its submission or editing form | Remove or change that reference on the process first |
| A space will not delete | The space still holds a submission type or process | Delete or move its types and processes first |
| Abstract submitters land on the wrong page after completing the process | The Event Abstract Process has a success-route override pointing somewhere else | Clear the override, or set it to /abstract/abstractsCenter, so submitters return to the Abstract Center |