Workflow decisions
Choose where work belongs in Edmissa without duplicating the full setup guides.
Use this reference when an admin needs to decide which Edmissa area should hold
a piece of work. It is a decision guide, not a setup walkthrough.
Start with the thing users are trying to do:
| If the team needs to | Use | Why |
|---|
| Review new student interest before creating long-term records | Leads | Leads give users a review step for incoming information before it becomes daily student work. |
| Store information about the student as a person | Student profile | Student profiles hold identity, contact, study, source, ownership, and location details that can support multiple applications. |
| Track progress through an admissions, visa, enrollment, or service workflow | Application | Applications move through pipelines, stages, requirements, checklists, documents, tasks, comments, and approvals. |
| Assign follow-up work to a person with a due date | Task | Tasks make ownership and timing visible. |
| Collect or review a file | Document | Documents store uploaded files and connect them to the right student profile or application. |
| Store a reusable data point | Field | Fields define the information Edmissa can collect, display, validate, search, and report. |
| Decide which fields users see in a form | Form template | Form templates arrange existing fields into forms for creation, editing, intake, and stage work. |
| Give users repeatable steps to complete | Checklist | Checklists turn repeatable work into items users can complete, warn on, or block on. |
| Trigger work automatically after a clear event | Automation | Automation rules create tasks, notifications, or workflow updates after a matching moment. |
| Show where an application is in a workflow | Pipeline stage | Stages represent the current work state and control movement, timing, access, notifications, and requirements. |
| Question | Choose | Do not choose |
|---|
| Is this incoming information that still needs review? | Leads | Do not create a student profile until the Lead is real, useful, and checked for duplicates. |
| Does this information describe the student across all future work? | Student profile | Do not put one university, deadline, offer, or visa outcome into student fields when it belongs to one application. |
| Does this work have stages, requirements, or a final outcome? | Application | Do not use only tasks when users need workflow reporting or stage movement. |
| Is this a small action with an owner and due date? | Task | Do not create a new pipeline stage for ordinary follow-up work. |
| Is the main item a file users must upload, review, replace, or expire? | Document | Do not store file status in notes or text fields when a document type can track it. |
| Decision | Use | Good first question |
|---|
| What information should Edmissa store? | Fields | Is the value about the student, or about one application? |
| Which fields should users see together? | Form templates | Who fills this in, and at what moment? |
| Which steps should users complete every time? | Checklists | Should unfinished items only guide users, warn them, or block progress? |
| Which moments deserve automatic action? | Automation | Is the trigger clear enough to run without a person deciding each time? |
| Which work states should appear on the board or reports? | Pipeline stages | Does this represent a real state of application work, not just a task? |
| Which files should be accepted and reviewed? | Document types | What format, size, scope, expiry, and approval rules does this document need? |
Use this table before creating fields, forms, or reports.
| Information | Better home | Reason |
|---|
| Name, date of birth, nationality, passport number, email, phone | Student profile | These describe the student and usually stay useful across applications. |
| Preferred destination, study level, source details, assigned counselor | Student profile | These guide recruitment and follow-up before or across applications. |
| University, program, intake, application deadline | Application | These can differ for each application. |
| Offer status, submission date, visa appointment, visa outcome | Application | These belong to one workflow and one result. |
| Notes about a phone call or handoff | Student profile or application, based on context | Put the note where the next user will look for the related work. |
| Follow-up date or reminder | Task | A field or note will not create the same ownership and due date visibility. |
If the same student can have two different answers at the same time, the value
probably belongs to an application.
| Situation | Recommended choice |
|---|
| New web form submission needs review | Keep it as a Lead until a user checks it. |
| The student already exists | Link the Lead to the existing student profile when the data is trustworthy. |
| The student is real but not ready for an application | Create or update the student profile and assign follow-up. |
| The student is ready to start a specific service | Create an application from the correct student profile. |
| The form should create both student and application work | Use a form and workflow setup that creates the student profile and starts the application together. |
Search before creating. Duplicate student profiles make documents, tasks, and
applications harder to trust.
| Need | Use | Example |
|---|
| One person should do one follow-up by a date | Task | Call student about missing bank statement. |
| Several steps should be completed the same way each time | Checklist | Confirm passport validity, review financial evidence, record submission date. |
| The application is in a different state of work | Stage | Document Collection, Visa Application, Visa Approved. |
| A task needs several steps before it can be completed | Task with checklist | Review document pack and complete each review item. |
| Stage movement should stop until required work is complete | Stage requirement or blocking checklist | Do not move past Document Collection until required files are ready. |
Do not add a stage for every small action. A stage should describe where the
application is, not everything a user must do while it is there.
| Need | Use | Reason |
|---|
| Store the uploaded file | Document | The file can be previewed, reviewed, replaced, and tracked. |
| Define the kind of file users should upload | Document type | The type controls accepted formats, size, expiry, scope, upload mode, versioning, and approval. |
| Ask for a value, date, choice, or note | Field | Fields store structured information that can appear in forms and views. |
| Ask for a file inside a form | File-upload field connected to a document type | The form collects the file while document rules still control it. |
| Track whether a file is acceptable | Document approval or checklist | Approval answers whether the uploaded file is acceptable. A checklist tracks human review work. |
Use documents for files. Use fields for data about the work. Use checklists for
review steps around the file.
| Question | Use |
|---|
| Do we need a new data point? | Create a field. |
| Do we need users to see existing fields in a better layout? | Create or update a form template. |
| Do only some stages or roles need a different form? | Configure pipeline form management for that stage and role. |
| Do users need a quick form from the sidebar? | Use a form template with sidebar visibility when the form is used often. |
| Do users need fewer required fields in early intake? | Use a simpler form template rather than weakening the field design for every workflow. |
Create fields first, then arrange them in form templates. Form templates do not
replace fields.
| Use automation when | Keep it manual when |
|---|
| The trigger is clear and repeatable. | A person needs to judge whether the action should happen. |
| The action has a predictable owner or audience. | The owner changes based on context that Edmissa cannot reliably know. |
| The rule reduces missed follow-up. | The rule would create noise or duplicate reminders. |
| The team can test the rule with sample Leads, student profiles, and applications. | The workflow is still changing every week. |
| The result can be monitored after launch. | Nobody owns rule maintenance. |
Start with a few useful rules. Retire rules that users ignore.
| Admin decision | Recommended path |
|---|
| We need to collect passport files from students. | Create a Passport document type, then use documents, forms, or stage requirements where needed. |
| We need to know each student's preferred destination. | Create a student field and place it on the right student form template. |
| We need to track the university for each application. | Create an application field in the relevant pipeline and add it to the application form. |
| We need counselors to call new Leads within one day. | Use Leads for intake, assign ownership, and consider an automation rule that creates a task. |
| We need to stop visa applications from moving forward before review. | Use a stage requirement, approval, or blocking checklist on the relevant pipeline stage. |
| We need a manager to see delayed work. | Use stage timing, delay notifications, task reports, or a focused automation rule. |
| We need different forms for different stages. | Create form templates, then assign them through pipeline form management. |
| Guide | Use it for |
|---|
| Leads | Review incoming Leads before creating or connecting student profiles. |
| Student profiles | Manage student-level information and related work. |
| Applications | Create applications and move them through pipelines. |
| Tasks and follow-ups | Assign and complete follow-up work. |
| Documents | Upload, review, and track files. |
| Fields | Configure student fields and application fields. |
| Form templates | Arrange fields into user-facing forms. |
| Checklists | Configure repeatable work steps. |
| Automation Engine | Create workflow rules for tasks, notifications, and updates. |
| Pipeline stages | Configure application stages, timing, requirements, access, and notifications. |