Understanding CRM Registration Forms

 Overview

CRM Registration Forms are the forms you build and manage inside the ConexED CRM. CRM Registration Forms are a distinct feature from other form types in ConexED, such as Early Alert Forms, Appointment Intake Forms, and Milestone Forms. These forms are used for things like program applications, institution applications, and prospective student requests for information.

The CRM Registration forms offer configuration options that allow answers to update a user's ConexED profile automatically. Many of such updates are connected to automated actions in the system, including automated communications.

This article gives you the big-picture view of how CRM Registration Forms work — what they're for, how student answers move into your data, and how submissions get reviewed.

At a Glance

How It Works

A CRM Registration Form moves through the same basic lifecycle regardless of how it's configured:

1. A student opens and completes the form. Some forms can be started, saved, and finished later — staff can view these in-progress submissions, including which fields have been filled in so far, from the Registration Form Submissions section in the CRM. Uploaded files aren't visible until the student finishes and submits. Forms can also be filled out by prospective students who don't yet have a ConexED account — submission triggers an account verification email prompting them to confirm their address and set a password.
2. The student submits the form. This is the key moment: any mapped field — profile name fields, student attributes, cohort placement, phone/SMS opt-in, or advisor/group assignment via Custom Response Router — writes to the student's profile immediately, regardless of the form's review mode.
3. Configured automated actions can fire at the same moment. A form can be set up to automatically create a Recruitment Task assigned to a specific recruiter or team, or trigger a Recruitment Pipeline Options action tied to the student's recruitment or cohort status — both fire at submission, alongside the mapped-field profile writes.
4. The submission is evaluated according to the form's review mode:
   • Manual Review — the submission enters a Pending queue for a staff reviewer to approve or deny. When submissions are pending review, designated reviewers can approve or deny them from the Registration Form Submissions queue — see Reviewing CRM Registration Form Submissions (coming soon) for details.
   • Auto Approve — the submission is approved instantly and synchronously; no staff action is required.
   • Cohort Decision — approval follows the outcome of the linked cohort application.
5. Notifications go out, if configured. Admins can attach a CRM email template to each of the six decision outcome slots — Manual Review – Approved, Manual Review – Denied, Auto-Approve, Cohort Decision – Approved, Cohort Decision – Partially Approved, and Cohort Decision – Denied — or set any slot to None to suppress that outcome's email entirely. 
   For Cohort Decision forms, a separate Suppress Cohort Placement Email option is also available; when enabled, it prevents a system-generated cohort placement notice from being sent alongside the approval — it does not alter the content of the decision email itself. These emails are not held for quiet hours — they send immediately, unlike Drip Campaign messages, which defer during a student's quiet hours window. Templates support short codes such as [recipient_name], [recipient_email], and [recipient_phone] to personalize the message.

The one thing to remember: review mode controls whether a submission record shows as Pending or Approved. It does not control whether profile data gets written — that happens at submission for every mapped field type, in every review mode, including Manual Review. If a student's profile or cohort placement needs to be reversible pending staff sign-off, that reversal has to be handled manually; it isn't built into the review workflow.

Things to Know

• Profile data writes at submission, not approval — in every review mode. This is easy to assume otherwise, especially for Manual Review, but it's true across the board.
• CRM Registration Forms are not the same as Early Alert Forms, Appointment Intake Forms, or Milestone Forms. If you're looking for one of those, this isn't the right article.
• Field types fall into three groups: mapped (writes to the student's profile), unmapped (visible to staff only), and structural (organizes the form itself, like steps and display toggles).
• Changing a form's review mode only affects future submissions. It does not retroactively change submissions already sitting in the Pending queue.
• The same email address can be used across multiple institutions. A submission isn't blocked as a duplicate just because that email is already registered at a different institution — institution-scoped accounts are treated separately.
• The SMS consent checkbox uses updated compliance language. If a form includes a phone/SMS opt-in field, the checkbox text was clarified to more explicitly state consent terms — worth a quick check on any older forms to confirm they're showing the current wording.

Use Cases

Decision Guide

Use this table to decide how to approach a new or existing form:

Configuration Overview

At a high level, building and managing a CRM Registration Form involves:

• Building the form from the CRM Registration Forms index, using the field types available in the form builder (name fields, attributes, cohort placement, phone/SMS opt-in, advisor routing, and structural elements like Form Step Sections and Display Toggle Fields).
• Setting the review mode in the form's Settings, unless the form contains a Cohort Application field, in which case Cohort Decision is applied automatically.
• Configuring notification templates for each decision outcome from the form's Manage Options page — including short codes for personalization and a None option to suppress a given outcome's email entirely.
• Setting up automated Recruitment Task creation, if the form should generate a task for a recruiter or team upon submission.
• Managing the forms library from the index page, which supports filtering by Active, Inactive, or All status.

Next Steps

• Understanding Registration Form Submission Review Modes
• Registration Form Builder Enhancements