Glossary
Look up common Edmissa terms.
Use this glossary when you need a stable definition for a term used across Edmissa documentation. For step-by-step work, follow the linked guide.
| Term | Meaning | Related guide | | --- | --- | | Active account | A user account that can sign in and work in Edmissa. | Users | | Application | Work that tracks a student's progress through one configured pipeline, such as admissions, visa processing, enrollment, or another service. | Applications | | Application field | A field whose value belongs to one application in one selected pipeline. Use it for values that can differ between applications, such as university name, deadline, offer status, or visa outcome. | Application fields | | Application number | The generated number users use to identify, search for, and discuss an application. | Number formatting | | Approval | A review step where an allowed user confirms, declines, or requests revision before work continues. Approvals can be connected to stages, checklists, or document review behavior. | Pipeline stages | | Assigned user | The user responsible for the next action on a Lead, student profile, application, or task. | Student profiles | | Audit logs | Workspace activity history that admins can filter, review, and export for investigation or oversight. | Audit logs | | Checklist | A working list of steps users complete on an application stage, task, or approval verification flow. | Checklists | | Checklist template | The reusable setup that creates working checklists for applications or tasks. | Checklists | | Combined form | A form template that collects both student profile information and application information in one workflow. | Form templates | | Country and region configuration | Local setup choices that differ by market, branch, destination, or operating region. | Country and region configuration | | Data access level | The amount of access a role grants for a work area, such as no access, view only, manage records, or full control. | Permissions | | Data scope | The set of records a role can use, such as own, assigned, team, or all. | Permissions | | Display configuration | The setup that controls which fields appear in profile and application views, how they are grouped, and how users scan them. | Display configuration | | Document | A file connected to a student profile, application, form upload, checklist, or review step. | Documents | | Document scope | Whether a document type is available on student profiles, applications, or both. | Document types | | Document type | A configured file category that controls labels, accepted formats, size rules, upload mode, expiry tracking, versioning, and approval behavior. | Document types | | Field | A configured data point shown on student profile forms, application forms, lists, filters, reports, and daily work views. | Fields | | Field group | A named section that keeps related fields together, such as identity information, contact information, study preferences, or application details. | Student fields | | Field name | The system key generated from a field label and used by forms, imports, connected workflows, and reports. Review it before saving a new field. | Student fields | | Form template | A reusable form layout that decides which fields users see, which fields are required, how sections are arranged, and where the form appears. | Form templates | | Lead | Incoming student interest from a public form, connected lead capture channel, integration, or custom webhook before it is converted or connected to a student profile. | Leads | | Lead source | The channel or origin of a Lead, such as a website form, referral partner, study abroad fair, walk-in, phone call, or connected form. | Lead sources | | Location | A branch, office, or operating group used for access, assignment, reporting, and responsibility. | Locations | | Pipeline | A configured workflow that defines the path an application follows from creation to outcome. | Pipelines | | Pipeline form management | The setup that chooses which form template appears at each application stage and for each role. | Pipeline form management | | Priority | A label that helps users sort attention across applications or tasks, such as Low, Medium, High, or Urgent. | Applications | | Role | A reusable access profile assigned to users. A user can have more than one role, and access combines across assigned roles. | Roles | | Stage | A step inside a pipeline that tells users where an application is now, what should happen next, and which rules apply before it moves forward. | Pipeline stages | | Stage type | The meaning behind a stage for status, reporting, and outcomes, such as New, In Progress, On Hold, Completed, Withdrawn, Failed, or Lost. | Pipeline stages | | Student field | A field whose value belongs to the student profile across applications, such as name, contact details, nationality, passport number, or study interest. | Student fields | | Student profile | The daily home for information about a student, including contact details, study preferences, source context, ownership, location, applications, documents, and tasks. | Student profiles | | Supervisor | The user another user reports to for team visibility and manager review. | Users | | Task | A follow-up or action item assigned to a user, often with a due date, priority, status, discussion, and optional checklist. | Tasks and follow-ups | | User | A person who can sign in to Edmissa and whose access is controlled by account status, roles, locations, supervisor setup, and permissions. | Users | | Workspace | The Edmissa working area for an agency or team. It contains the team's users, roles, locations, settings, Leads, student profiles, applications, documents, and tasks. | Configure Edmissa |
Common decisions
| Decision | Use this guidance |
|---|---|
| Student field or application field? | Use a student field when the value belongs to the student across applications. Use an application field when the value belongs to one application or one pipeline. |
| Document type or checklist? | Use a document type to define a file category and upload rules. Use a checklist to define human work that must be completed. |
| Stage or task? | Use a stage for the application's workflow state. Use a task for a specific follow-up assigned to a user. |
| Lead or student profile? | Use Leads for incoming student interest that needs review. Use a student profile once the team is ready to work with the student as an active profile. |
| Role or user setting? | Use roles for reusable access patterns. Use user settings for the person's account status, login details, locations, supervisor, and assigned roles. |