An application process can require up to eight items before someone earns or renews a certification. This article explains what each requirement checks, how Rhythm calculates the application’s percentage complete, and when an application moves forward automatically instead of waiting for staff review.
What Counts as a Requirement
A certification application process can use any mix of eight requirement kinds: a course, an exam, a fixed or calculated number of credits, completed references, an answered field on the application form, a condition written as an expression, a manual staff check, or a custom requirement checked by a function your implementation team set up. When someone files an application under that process, Rhythm copies those requirements onto the application and checks whether each one is currently met.
How Each Kind of Requirement Is Checked
Course. A course requirement is met when the applicant’s most recent registration for one of the required courses satisfies the requirement. Your configuration decides which registration status counts. Completed and Attended registrations can both count, but some accounts have only seen Registered or Attended satisfy the requirement while a Completed status written by an outside learning system did not. If a completed course is not updating the requirement, compare the exact status the requirement expects with the status your integration writes. Only the latest registration counts, so registering again or canceling a registration after an earlier one met the requirement makes it unmet again. For a requirement built from several grouped webinar course offerings, mark each required registration Completed by hand; the certification requirement updates automatically once every required registration has that status. Zoom entry and exit times do not complete the requirement by themselves because the registration’s own status is what matters. For an organization application, Rhythm checks the organization’s own contact, not everyone who works there. Rhythm measures the time frame from the application date, not from the certification’s own cycle. Completing a course by itself does not create a certification; the learner still needs a certification application under a process before that course can count toward one.
Exam. An exam requirement works the same way as a course requirement. Only the applicant’s latest registration for one of the required exams counts, so a new registration or a failed retake after an earlier pass makes the requirement unmet again. Rhythm measures the time frame from the application date, and passing the exam is not enough by itself. The pass also has to fall inside the timing window your requirement uses, with operators such as “before the” or “after the” application date. For example, a requirement set to “1 year after the application date” only counts an exam taken after that future date, so an exam the applicant already passed will not satisfy it. A requirement that needs the exam passed at least a number of months after the application date treats an earlier pass as too soon and leaves the requirement unmet. If a passed exam is not satisfying the requirement, check the operator and time frame before assuming the result is wrong.
Warning
Requirement type matters as much as requirement content. If the requirement type in your certification application process does not match the status values your connected course or exam system sends, an application can stay in Missing Requirements even after the learner finishes the course or exam. Confirm the two line up, especially after connecting a new provider.
Relative-date options like “on the application date,” “before the,” and “after the” application date all use the application’s own date as the reference point. Rhythm does not use today’s date or the certification’s cycle. A requirement anchored “on the application date” only counts a course or exam dated on or after that point, so a course or exam completed earlier will not satisfy it. The requirement editor may flag that setup as probably incorrect. Some operators, especially “after the” and “on,” are easy to select by mistake and can trigger a warning. Treat that warning as a prompt to confirm you picked the timing you intended, and test the result rather than assuming it is correct. This timing model can also be a poor fit when applicants start the application so they can buy the required course, because Rhythm checks the registration against the application date rather than the purchase date. Review this configuration carefully if that describes your process.
If the application does not yet have an application date, such as a brand-new draft, a course or exam requirement measured from that date can fail with a server error instead of a clear message. Changing the relative-date option does not always change which date the calculation uses, so test any change before relying on it. If a course or exam requirement still will not update after you confirm the registration status and timing configuration, contact Support.
Credit. A credit requirement is met when the credits counted toward the application reach either a fixed number or a number your administrator calculates with a formula that uses the application, the applicant, and the certification. Credits do not need to be in Verified status to count; an unverified activity or credit can still satisfy the requirement. Each requirement is tied to one specific credit type, so Rhythm does not total credits across multiple types for a single requirement. There is no built-in way, including a custom expression, to require a combined total across types instead. Credits an applicant logs over time count automatically once they are recorded, but only for reusable credit types. A single-use credit still needs to be applied to the application by hand; see Apply Credits to an Application. When Rhythm counts credits automatically, it reads only the first page of the applicant’s credits, so someone with an unusually large number of credits could be under-counted. If a formula fails or returns something other than a number, Rhythm treats the requirement as unmet and does not record why. A credit requirement shows as unmet, not partially met, until the full amount is reached. For example, an applicant with 39 of a required 300 credits still shows that requirement as unfulfilled rather than showing partial progress.
Reference. A reference requirement is met when the applicant has enough completed references of the required type. As with credits, Rhythm reads only the first page of the applicant’s references, so an application with a very large number of references could be under-counted.
Field. A field requirement is met when the applicant answers the selected field on the application form. An empty value, “no,” or “false” counts as unanswered, and the number zero also counts as unanswered. Nearly anything else counts as an answer, including a typed word like “maybe” or the text “0”. This requirement only works when the field named in the requirement exactly matches the form field’s underlying name. If the names do not match, an answer the applicant can see on the screen may not register as answered for this requirement.
Tip
If applicants can move past a question you expected to require an answer, check whether that field is marked required on the application form itself. A field requirement here only blocks progress when the form’s own field is required; it does not check how the form was built. If an applicant sees a generic message such as “Error during order preparation: The specified key does not exist” during checkout, check for a required checkbox earlier in the form that was left unanswered. That kind of validation failure often appears as this generic error instead of pointing to the specific field.
Expression. An expression requirement is met when a condition your administrator writes evaluates as true for the application. The same expression is shared by every application that uses the process, so a syntax error can stop every application under that process from updating correctly, not just the one you are reviewing. Expressions are evaluated against the application and its contact, the same objects described in Rules and Expressions Explained. They do not support the application form’s merge-field notation, so pasting a merge-field token or curly-brace syntax into the expression editor produces an undefined-variable or syntax error instead of the value you intended. The editor’s validation can also behave inconsistently. Some expressions only save after you first enter a placeholder value and then replace it with the real one, and an expression that saved and worked before can later fail validation after being copied and pasted, even when the meaning did not change. If an expression will not save or suddenly errors, try retyping it directly instead of pasting, and confirm it still evaluates the way you expect after any edit.
Manual. A manual requirement is left entirely for a person to decide. Rhythm keeps the status on a manual requirement exactly as someone sets it, including a status set through a Portal update if your account allows applicants to update their own applications there. A manual requirement left at “pending review” still counts as missing.
Custom. A custom requirement is checked by a function your implementation team configured. If automatic approval is turned on and that function fails while it runs, Rhythm treats the requirement as met anyway. This means the application can still move forward even though the custom check did not complete successfully.
Percentage Complete and Overall Status
Every application shows a percentage complete, calculated from the weight of each requirement the application actually carries. An application with no requirements shows 0% complete, not 100%. Rhythm uses the weights copied onto the application when it was created. If your administrator later changes a requirement’s weight on the process, that change does not update applications that already exist under it. The percentage reflects only requirements that are fully met. A partly satisfied requirement, such as a credit requirement still short of its total, contributes nothing until it is completely fulfilled, so the percentage can look lower than the applicant’s real progress. This display is part of the requirement tool itself and cannot be turned off or hidden.
When every applicable requirement on an application is met, Rhythm moves the application forward automatically if the application process is set to approve automatically. If the process does not approve automatically, the application moves to a pending-approval state so a staff member can approve it by hand. After an application has been approved, Rhythm never moves it backward automatically, even if a requirement it once met later stops being met. An approved application’s status and display no longer depend on a requirement’s exam score or any other requirement result changing afterward.
There is no separate built-in status for an application that staff already reviewed but that is still waiting on one last requirement, such as an exam. It stays in whatever state its unmet requirements create, typically Missing Requirements, until that requirement is met. That remains true even if staff looked at it earlier. Because an application can show Missing Requirements until every requirement, including a final exam, is complete, consider adding a short note to the application form or confirmation page. This helps applicants understand that the status does not mean their application was lost or rejected.
Only applications in a pending-approval state sync to a related Submissions review space, if your account uses one. An application in Missing Requirements or any other status does not appear there.
Tip
If applicants sometimes pass their exam after staff have already reviewed their application, automatic approval can help. Recording a passing exam score completes the exam requirement, and with automatic approval turned on, the application moves forward on its own instead of waiting for a second manual step. This is not a way to retroactively fix an application staff already approved by hand. Turn on automatic approval before approving, not after, because there is no way to make an approved application re-check a requirement later.
When an application process does not approve automatically, submissions that meet every requirement wait in Pending Approval. From there, a staff member can activate or approve the submission by hand, which updates its status the same way approving it directly on the application would.
When Requirements Are Recalculated
Rhythm recalculates an application’s requirement results, missing-requirement count, percentage complete, and status whenever the application is saved. Rhythm also recalculates them whenever a related record the application depends on changes, such as a registration, a reference, or a credit. Whether the application needs staff approval or moves forward by itself depends on the automatic-approval setting on its process. When that setting is off, every application that meets its requirements still waits for someone to approve it. If you are investigating why an application’s status changed and an end user could not have made the edit themselves, remember that applicants cannot edit an application once it is submitted. Check whether the change lines up with one of these automatic recalculations before assuming someone touched the record by hand. The audit history can show the recalculation itself as the source of the change.
Approval only checks requirements once. If staff approve an application before its exam requirement is met, recording a passing score afterward does not go back and fulfill that requirement or move the application again. Rhythm checks requirements before approval, not after, so an early approval means a later exam result has no further effect on that application.
If your administrator changes a process’s requirements after applications already exist under it, those applications keep the requirements they already had. A new application uses the process’s current requirements instead. If a requirement is removed from the process while an application still shows it as unmet, that application stays in a missing-requirements state until a staff member manually marks it fulfilled or not applicable. An application only stays in Missing Requirements when it actually carries an unmet requirement. If you set that status on an application that has no outstanding requirements, Rhythm reverts it to whatever status its requirements call for, such as Pending Approval. If several applications were left in the wrong state this way after you corrected a process’s requirements, you can update them together with a bulk update from a query instead of opening each one individually.
To test whether a change to a requirement will make a certification generate as expected, edit it directly at Certifications › Setup › Applications › Processes, open the process, and edit the specific requirement under Requirements.
Related
Which Application Processes You Can Use explains what decides which of these processes, and their requirements, an applicant is offered in the first place. Expressions used in expression requirements follow the same rules as elsewhere in Rhythm; see Rules and Expressions Explained for how they are written.