Edmissa docs

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

DecisionUse 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.

On this page