Person is the single CRM identity for someone in one school. It covers a prospect, a customer, a student, or a member of the school team. A Person can exist without a Cohorte user account. “Lead” describes the person's current interest or CRM facet; it is not a second object that must later be converted into a Person. The same person can acquire further context without changing identity.
Maya Chen starts with an Instagram handle in her school's People directory. The owner can record her before knowing an email address. When Maya answers a qualification form, that response becomes an application, with its own submitted answers and triage status. The application is not an account, offer, or enrollment. Its status and the contact's CRM status are separate; do not read one as an automatic update to the other.
| Concept | What it represents | What it does not do |
|---|---|---|
| Person | One school-scoped CRM contact, potentially without email or user account | Does not grant sign-in or course access |
| Lead | Interest or a derived CRM state of a Person | Does not create a separate Lead record or conversion step |
| Application | Maya's submitted answers to one published form version, plus a separate triage decision | Does not automatically admit, enroll, or sell to her |
| User account | A way for someone to authenticate; school membership has a Person identity | Does not by itself prove purchase or enrollment |
| Offer | The commercial terms and payment address for a purchase | Does not mean Maya has paid or joined a program |
| Enrollment | Maya's participation in a program, optionally in a cohort | Is not created by merely answering a form |
Open CRM → People to inspect Maya's known contact context. The directory can show a Lead facet, but it remains a view of Person records. Open CRM → Forms → Responses to read what Maya answered and what an owner/admin decided. The response detail retains the wording and answer type from the form version she saw, even if the draft is edited later.
A form respondent supplies a name and email address for the response. That submitted identity is evidence about the applicant; do not infer that the response itself grants a school account or settles whether an existing contact with a similar name is the same human. If two Person records truly describe Maya, an owner/admin can link them as a reversible alias after checking. Email on Person is optional and is not a unique database identity; the application email does not change that rule.
The public API currently exposes People import and alias operations, not full Person list/read/edit, form authoring, or application triage endpoints. Form and triage work happens in the school screens. A broader opportunity pipeline is deferred.