An application process is one complete route into a certification program, such as first-time certification, renewal, reinstatement, or transfer. It connects the application form, fee, expiration rules, requirements, emails, and application paths, including the Console, Portal, and training providers.
What It Controls
A process belongs to one program. Its settings control who can use it, what applicants submit and pay, how requirements are checked, which renewal or reinstatement windows apply, whether applicants see it in the Portal, and which emails Rhythm sends.
Certifications used to organize this setup under a different path. If you are following an older screenshot or support answer, use the navigation below instead of the menu wording shown there.
Where to Find It
Go to Setup › Applications › Processes to see every application process in your account, or filter the list to one program. Select Create Application Process to add a process, or use Edit or Clone on an existing row.
Tip
The list’s Last Changed column can show “a few seconds ago” for every process, regardless of when each process actually changed. To find the real modification date, open that process’s audit log, which records the actual date and time of the last change.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Program | Any program | None | Sets which program this process leads into. The process identifier always starts with the program identifier. |
| Type | Certification, Renewal, Reinstatement, Transfer | Certification | Sets the route type. Renewal and Reinstatement show extra options for their timing rules, while Transfer shows which programs applicants can transfer to. |
| Customer Type | Contact, Organization | Contact | Sets whether the process is for individual applicants or organizations. |
| Application Form | A published Certifications application web form | None | Sets the form applicants complete. If the form places Collect Payment Details after Review & Confirm Application, the customer-information refresh section on the review screen can spin indefinitely instead of loading. Put Collect Payment Details earlier in the form to avoid this. |
| Base Fee | An application fee for the chosen program | None | Sets what applicants pay to use this process. |
| Certification / Application Expiration Rule Sets | Expiration rule sets | None | These are two separate settings, and both are required. The certification expiration rule set controls how long the resulting certification lasts, while the application expiration rule set controls how long an in-progress application stays open before the applicant must start again. |
| Restrict to certain organization types | Off, or a multi-select | Off | Limits the process to applicants from selected organization types. Applicants with no organization are still allowed through this restriction. |
| Available to training providers | On/off | On | Controls whether a training provider can use this process for an applicant. |
| Prefill from certification profile data | On/off | On | Starts the application form with the applicant’s existing certification profile data, when one exists. |
| Automatically approve once requirements are met | On/off | Off | Approves the application as soon as all requirements are met, without staff review. |
| Renewal Window (days) (Renewal type) | A number of days | None | Sets how many days before expiration an applicant can start renewal. |
| Reinstatement Period (days) (Reinstatement type) | A number of days | None | Sets how many days after expiration an applicant can still reinstate through the Console form. You cannot set this to unlimited from the form itself. |
| Show in Portal / Display name / Short Description | On/off, then text | On for new processes | Controls whether the process appears to Portal applicants, and how it appears. |
| Eligibility Criteria | Off, or a rules editor | Off | Narrows who is offered this process, in addition to organization type. Turning this off and saving removes any criteria you had set. |
| Certificants (in Eligibility Criteria) | The following are true / The following are NOT true, then one or more programs | None | Requires or excludes applicants who hold a certification in the selected programs. |
| Grandfathered Certification Restrictions | Off, or a program list with Standard/Inverse behavior | Off | Limits the process to applicants who do, with Standard behavior, or do not, with Inverse behavior, hold an active, grandfathered certification in one of the listed programs. |
| Enable Course/Exam Registration | On/off, each with its own registration process | On for new processes | Controls whether applicants can register for a course or exam as part of this application. |
| Confirmation Email / Certification Activation Email | An application notice | None | Sets the emails sent when the application is paid and when it results in a certification. |
| Override Checkout Settings | Off, or your own checkout panel | Off | Lets this process use its own checkout setup instead of your account’s Certifications checkout defaults. |
Requirements
Each process has its own requirements that an applicant must meet. A requirement can be based on course completion, exam results, credits, a custom field value, a reference, an expression, a custom integration check, or a manual staff sign-off.
Select Add Requirement to open the requirement editor. Every requirement needs a Requirement Name, a Requirement ID that Rhythm suggests from the name, and an optional Weight that affects how much it counts toward overall completion. You can edit the Requirement ID until you save the process. You can also make a requirement apply to only a percentage of applicants, chosen at random when the application is created.
Tip
A language-specific version of a process, such as separate English and Spanish recertification processes for the same program, counts as its own process for credit applicability. If your association’s activity types list which application processes their credits apply to, list each language-specific process separately. A credit applied under one language’s process does not automatically count toward a requirement on the other language’s process.
If you need to offer an application in more than one language and Rhythm does not natively support showing one process’s content in multiple languages, plan to build a separate process and form for each language. Do not expect one process to display differently by language.
Tip
If a course or exam requirement’s qualifying time frame does not say “before,” Rhythm shows an in-form warning because the setting would exclude courses or exams completed before the application was submitted. The warning does not block saving, so review the time frame carefully if you see it.
Checkout and Order Details Pages
When your application form collects payment, the pages before the Success page matter, not just the fields on them. The Confirm Order Details component depends on a Collect Order Details component appearing on an earlier page of the same form. If Collect Order Details is missing, submission can hang and then fail. For a process that ends with checkout, put Collect Order Details and then Confirm Order Details immediately before the Success page, and put the form’s submit button on the Confirm Order Details page itself.
Warning
Adding header text to a Collect Order Details component can stop the application from advancing past that checkout step. If an application form stalls at checkout and you customized that component’s header, remove the added text, save the form, and check any other forms that use the same component setup.
Dependencies and Precedence
- A process's identifier is tied to its program for good. Because the identifier is prefixed with the program’s identifier, you cannot move a process to a different program later by changing the Program field on an existing process.
- Requirements must be internally consistent to save. Two requirements on the same process cannot share a Requirement ID. A process also cannot have more than one reference-type requirement for the same kind of reference. Rhythm refuses both at save and shows a specific error; see Validation and Errors.
- A credit requirement can exclude certain activity types. When you restrict a credit requirement by activity type, you must select at least one activity type. Credits with no linked activity always count, regardless of this restriction.
- A calculated credit formula can be tested against a real application before you save, so you can confirm that it evaluates the way you expect.
- Organization-type restriction and eligibility criteria are independent filters. Both narrow who is offered the process, and a process can use either, both, or neither.
- Certificants criteria can target different audiences for the same program. To show a different join-style process to people who dropped a certification than to people who never held it, set one process’s Eligibility Criteria to Certificants “The following are true” for that program, so only past holders see it. Then set a first-time process to “The following are NOT true” for the same program, so only people who never held it see that one.
Change Impact and How to Revert
Changes to a process’s fee, requirements, renewal window, or eligibility rules affect applications that start after the change and applications that are still open. They do not retroactively change an application that was already submitted.
After you change a process’s form, fee, or confirmation email, submit a test application through it. This confirms that the application record is created and the confirmation email actually goes out, instead of relying on the setup screen alone.
To stop offering a process without deleting it, turn off Show in Portal to hide it from the Portal. Then remove it from any Console apply flow you control. There is no single inactive switch that hides a process from every apply path at once.
Permissions
You need administrator-level access to Certifications Setup to open Application Processes setup and to create, edit, clone, or delete a process there. Staff who process applications for a contact or organization use a separate day-to-day permission and do not need this setup access.
Validation and Errors
| Situation | What you'll see |
|---|---|
| Two requirements share the same Requirement ID | “Requirements must have a unique identifier” |
| Two reference-type requirements for the same reference type | “You may not have multiple reference requirements for the same type of reference” |
| A requirement ID you're typing is already used on this process | “The ID you've specified is already taken. Please choose another requirement ID” (shown as you type, in the requirement editor) |
| Organization-type restriction turned on with no types chosen | Save is refused. |
| A required field like Application Form, Base Fee, or an expiration rule set is missing | The field is named in the form’s error panel. |
Rhythm refuses to delete a process while any application still references it. Remove or reassign those applications first, or leave the process in place and stop offering it as described above.
If a Portal applicant sees "There are no processes available to you at this time", do not assume the cause is always an eligibility or organization-type restriction. Check whether Show in Portal is turned off for the process that should apply to them, because that setting alone produces the same generic message.
Related Tasks
Set up application fees in Application, Course, and Exam Fees. The notices a process offers as its confirmation or activation email come from Application Notices and Status Reasons. Build the application form as a web form; see Web Forms. Processes lead into a Certification Program, which must exist first.