Use the glossary while reading lessons, articles, and exercises so vocabulary never becomes a blocker.
The line that defines what a backend endpoint accepts, returns, and promises to protect from callers.
Example: An API boundary can state that a request may update a job note but cannot change billing state.
Concrete conditions that describe what must be true for a requirement to be accepted as working.
Example: Acceptance criteria can say a saved owner appears on the queue row and the detail screen after assignment.
The practical outcome that shows a requirement has been built in the intended way.
Example: Acceptance intent can say the reviewer should be able to confirm a request was assigned, saved, and visible in the queue.
A line that separates what someone can reach from what should stay locked, hidden, or request-only.
Example: A locked lesson player can still allow a simple public preview page.
A simple user-facing explanation of why access is available, locked, expired, or needs an action.
Example: An access message can say that a lesson requires Academy Plus and Year Three completion.
A plain rule that connects a role to an allowed action or view.
Example: Billing reviewers can view invoices and update billing status, but cannot edit service notes.
The set of records, fields, or actions a person is allowed to reach.
Example: A technician's access scope may include only requests assigned to them.
The current access condition that determines what a subscriber can use.
Example: Access state should make it clear whether a subscriber is active, limited, paused, expired, or canceled.
A named level of product access that groups allowed features or content.
Example: Starter and Academy Plus can be access tiers when they unlock different lesson paths.
A review that confirms interface labels, headings, focus behavior, contrast, and instructions support more learners and users.
Example: An accessibility check can verify that a dashboard card has a clear heading and form labels.
The name assistive technology can use to describe an interactive element.
Example: A menu button can have an accessible name like Open lesson navigation.
Records that should only be visible inside the correct customer, organization, or account boundary.
Example: Account-scoped data can include portal files, invoices, support requests, timelines, and dashboard summaries.
A clear record of who changed what, when it changed, and why it mattered.
Example: An accountability trail can show who approved a closeout and which note supported that decision.
The part of an interface where the main buttons or next steps live.
Example: A review screen may end with an action area for Submit, Edit, or Cancel.
The practical limit around what an automated action is allowed to change.
Example: An action boundary may allow a reminder message but prevent changing billing status without review.
A number or signal that points a team toward a clear next action.
Example: Unassigned urgent requests is an action metric because staff know what needs attention.
A signal that helps staff decide which task should be handled first.
Example: Action priority can combine urgency, age, customer impact, and current status.
A reminder that points someone toward a specific next action.
Example: An action reminder can say Review the waiting request before 3 PM.
The user action that asks the software to do something.
Example: Clicking Assign owner can be an action trigger in a support dashboard.
A compact report section that points staff toward a next decision or follow-up action.
Example: A summary of blocked requests by owner can help a manager decide who needs support.
A filter that is currently narrowing what the user can see.
Example: A chip that says Open shows an active filter on a support list.
A clear visual or text cue that tells users which portal area they are currently viewing.
Example: An active navigation state can highlight Documents while the user reviews uploaded files.
A record of meaningful actions or changes that happened in a workflow.
Example: An activity log can show that a ticket was assigned, updated, and resolved.
An ordered record of meaningful portal actions, file changes, status updates, and review events.
Example: An activity trail can show when a document was uploaded, reviewed, replaced, or shared with the client.
The visible record of which user, system job, or role triggered an important backend event.
Example: An actor trace can show whether a supervisor or an automated reminder path reopened the record.
The step that confirms the person triggering a backend action matches the role and identity the rule expects.
Example: Actor verification can check that the supervisor, not a regular staff account, approved the exception.
A bulk or record-level Django Admin action that changes selected records and needs careful review.
Example: An admin action can mark selected tickets as reviewed, but it should be limited to safe staff workflows.
A Django Admin control that lets staff narrow records by useful operational categories.
Example: An admin filter can show only open requests, escalated tickets, or records assigned to one team.
The set of fields shown in a Django Admin list so staff can scan records quickly.
Example: A ticket admin list display might show status, owner, priority, and updated time.
A manager or administrator view that shows health, exceptions, approvals, and intervention needs across portal work.
Example: Admin oversight can reveal overdue approvals, blocked queues, and work that needs reassignment.
A field shown to staff for review without allowing casual editing from the admin screen.
Example: A calculated invoice total can be an admin readonly field so staff can inspect it without changing it directly.
A staff-side helper screen, button, or workflow that makes repeated management work faster and safer.
Example: An admin utility can help staff update a queue without editing every record one at a time.
A check after a software change to see whether people are using it correctly and where they need support.
Example: An adoption review may compare completed workflow records, repeated questions, and missed steps after launch.
A sign that people are using, avoiding, misunderstanding, or depending on a new software workflow.
Example: Repeated support questions about the same status change can be an adoption signal.
The logic that groups or totals backend data so summaries stay consistent across the reporting pipeline.
Example: An aggregation rule can decide whether reopened jobs count in completed totals or stay in a separate bucket.
A state change the workflow explicitly permits when the required conditions are true.
Example: Moving a request from assigned to in review can be an allowed transition once the owner is set.
The chance that unclear wording causes a builder or reviewer to make the wrong assumption.
Example: Ambiguity risk rises when a requirement says make the dashboard better without naming the exact behavior needed.
Incoming information that can be understood in more than one way and should not drive automation without review.
Example: A request saying ASAP without a category or location is ambiguous input for routing.
A dependency between Django apps that makes one app harder to change without affecting another.
Example: If every app directly changes invoice status, billing behavior becomes tightly coupled to unrelated workflows.
The stable outer structure of an app screen, such as navigation, header, and main workspace.
Example: A dashboard app shell can keep the sidebar and header stable while the main content changes.
A protected workflow step that should be completed only by a role with the right authority.
Example: A manager approval action can be required before a high-value discount is applied.
A checkpoint that requires an approved decision before automation performs the next action.
Example: An approval gate can require manager review before a refund workflow continues.
A narrow exception path that lets a higher-trust role approve or reverse an action outside the normal route.
Example: An approval override can let a manager reopen a locked record after the required explanation is saved.
A work queue for items that require review, authorization, or rejection before work can continue.
Example: An approval queue can show estimates waiting for manager approval before clients see them.
An action that removes a record from active work without permanently erasing it.
Example: A resolved support ticket can be archived so it no longer clutters the active queue.
A task that has a clear owner responsible for the next step.
Example: An assigned task can show who owns the work and when follow-up is expected.
The person, role, or team responsible for the next step on a work item.
Example: A request may have a technician, reviewer, or support team as its assignee.
A summary that counts work items for a person, role, team, or queue.
Example: An assignee count can show how many requests are currently owned by the support team.
A reviewed action that moves responsibility for a work item to a person, role, or queue.
Example: A manager can use an assignment action to send a new request to the right staff queue.
The information a staff member needs to continue work without guessing why the item is assigned or blocked.
Example: Assignment context can explain that approval is waiting on a signed document uploaded by the client.
The moment software gives enough context to the next owner so work can continue without guesswork.
Example: A handoff can include the assigned owner, request status, needed follow-up, and customer context.
A rule that decides who owns a ticket, when ownership should change, and what happens when no owner is set.
Example: An assignment rule can send unowned urgent tickets to the next available support lead.
The current responsibility state of a record or task.
Example: A request can be unassigned, assigned to one person, or waiting for reassignment.
Access that depends on whether the record is assigned to a person or team.
Example: A staff member may edit a ticket only after it is assigned to their queue.
A saved file connection that belongs to a business record or workflow step.
Example: A service request can include an attachment record for a photo, receipt, or signed form.
A rule that explains when a file is required, optional, visible, or reviewed.
Example: An attachment rule can require proof of work before a task moves to complete.
The order and visual weight used to show what matters most on a screen.
Example: A dashboard can place blocked work above recent activity so users see risk before routine updates.
The saved timeline of backend changes that helps explain who changed a record, when it changed, and why the workflow moved.
Example: Audit history can show that a request was reassigned, reopened, and approved in a clear order.
A reliable history that helps people understand who changed what and when.
Example: An audit trail can show that a staff member archived a resolved request on Friday.
History that is easy to review because important actions are dated, attributed, and explained.
Example: Audit-friendly history helps staff understand a request without searching several message threads.
The set of records, screens, or actions a signed-in user is allowed to reach in a Django product.
Example: A dispatcher auth scope may allow job reassignment while a technician scope only allows updates on assigned jobs.
The process of confirming who a user is before the app treats them as signed in.
Example: A Django login form uses authentication to confirm that the username and password match a real account.
The decision about what a signed-in user is allowed to view or do.
Example: A staff user may be authorized to open an internal dashboard while a client user is not.
A rule that explains who is allowed to trigger a backend action and what checks must pass first.
Example: An authorization rule can require a dispatcher role before a job is reassigned.
The step an automated workflow performs after a trigger condition is met.
Example: An action can create a task, send a message, update a status, or add a review note.
A repeated workflow step that may be worth automating after the team checks value, risk, and review needs.
Example: A reminder sent after a scheduled appointment may be a stronger candidate than a rare manager approval.
A complete review plan that connects automation opportunity, routing, safeguards, observability, and recovery.
Example: An automation capstone plan can describe an intake-to-CRM workflow with review checkpoints and rollback notes.
A short walkthrough that explains the automated workflow, expected behavior, safeguards, and recovery path.
Example: An automation demo script can show how a lead moves from intake to CRM and what happens when a required field is missing.
A saved timeline of automation events that shows what happened, when, and which record was affected.
Example: An automation event log can show that a reminder was skipped because the request was already completed.
A practical review of workflow steps that may be safer, faster, or clearer when handled by software.
Example: An opportunity map can show repeated request follow-ups that staff copy by hand every day.
A readable summary of automation activity, results, exceptions, or failure patterns.
Example: An automation report can show daily reminder counts, skipped records, and review-queue volume.
A way an automated workflow could confuse people, send the wrong message, lose context, or make recovery harder.
Example: Automatically closing a support request before the customer confirms resolution is an automation risk.
A rule, pause, limit, or fallback that reduces the chance of unsafe automated behavior.
Example: An automation safeguard can stop a workflow from sending a message when approval is missing.
A compact collection of backend review notes, safeguards, and decisions that shows how a workflow was evaluated.
Example: A backend review portfolio can include a risk map, service contract note, query safeguard, and recovery plan.
A structured review of backend workflow changes before code or data rules are changed.
Example: A backend risk review checks status flow, ownership, and side effects before a service request workflow is updated.
A plain-language plan that connects records, statuses, rules, ownership, and follow-up.
Example: A backend workflow map can show how a request moves from intake to assignment, proof, reporting, and closeout.
A backend task that runs outside the main page request so repeatable work can happen on its own schedule.
Example: A background job can send a due-soon reminder after the request is saved instead of waiting for the user to stay on the screen.
Product work that should happen outside the immediate request because it may take time or happen after a trigger.
Example: Sending a reminder after a booking is created can be background work when it should not slow the page response.
A grouped update that changes several records in one guarded operation.
Example: A batch update can move selected tickets from waiting to assigned when the scope is clear.
A plain rule that describes what the software should do when a specific condition happens.
Example: A behavior rule can say a request marked urgent should appear above normal requests in the review queue.
A state change the workflow should refuse because the record is missing a required condition or is in the wrong state.
Example: A blocked transition can stop a ticket from closing before the follow-up note is saved.
Work that cannot move forward until a dependency, answer, approval, or required detail is resolved.
Example: Blocked work should show why it is stuck and what would unblock it.
A short explanation of what is preventing work from moving forward.
Example: A blocker note can say the team cannot review signup behavior until the route loads correctly.
A problem that happens when work crosses systems without the context, ownership, or confirmation needed.
Example: A boundary failure can leave a customer request in the website inbox without a CRM owner.
A mistake where a backend boundary exposes fields, actions, or assumptions that should have stayed behind the service line.
Example: A boundary leak can expose an internal review note through an endpoint meant only for customer-safe status updates.
A warning sign that responsibilities are mixed together or that a Django app has become too broad.
Example: A customers app that also sends reminders, calculates billing, and handles support queues may have boundary smells.
A small path that shows where the current screen sits inside a larger structure.
Example: A breadcrumb can read Dashboard, Support, Ticket detail.
The transfer of clear requirements, context, and constraints to the person who will build or revise the software.
Example: A builder handoff can include objective, users, behavior rules, inputs, outputs, constraints, and examples.
A guarded staff action that applies the same change to more than one selected record.
Example: A bulk action might assign several open requests to the same staff member after a clear confirmation step.
The practice of learning how work actually moves through a business before deciding what software should do.
Example: A discovery pass can show that customer requests arrive by phone, email, and web form before staff route them.
A saved item that represents something a business needs to track.
Example: A support ticket, service request, customer profile, or homework submission can be a business record.
A workflow moment where customer or lead context moves from one system, owner, or stage to another.
Example: A CRM handoff can move a qualified lead from intake to sales follow-up with required context attached.
A practical user path for creating, reading, updating, or deleting a record.
Example: A support ticket CRUD flow can include creating the ticket, reading details, updating status, and archiving when finished.
What the screen, job, integration, or other service reasonably expects a backend boundary to accept or return.
Example: A caller expectation can be that canceled jobs return a clear blocked message instead of an empty success response.
The approved single value or format the workflow treats as the trusted version for comparison and validation.
Example: A canonical value can keep status labels consistent so reports do not split one meaning across many spellings.
The notes, workflow examples, decisions, and checks used to prove a final project is clear and reviewable.
Example: Capstone evidence can include a workflow map, role table, metric note, rollout risk, and change-support plan.
A final project that brings several learned skills together into one planned, reviewable result.
Example: A capstone project can combine a scoped workflow, screen map, acceptance criteria, QA plan, and presentation.
A final structured review that pulls together the major product engineering decisions from a learning path.
Example: A Django capstone review can check app boundaries, workflows, testing, release notes, and supportability.
A clear project story that explains the problem, build decisions, outcome, and lesson learned.
Example: A case study can explain how a small portal feature moved from request to reviewed result.
The practical effect a software update has on roles, records, timing, support, or daily workflow.
Example: A new required closeout field may affect technicians, dispatchers, and managers who review completed work.
A dated record of meaningful changes and why they were made.
Example: A change log can record that a dashboard status label was revised after review feedback.
The practice of introducing software updates in a way that helps users understand what changed and how to keep working safely.
Example: A change-management note can explain a new approval screen, who it affects, and when teams should switch.
A short explanation that tells reviewers why a meaningful workflow change happened.
Example: A change reason can explain why ownership moved from dispatch to a manager review queue.
The help, owner, reference material, and response path available while users adjust to a software update.
Example: Change support can include a quick guide, office-hours window, support queue, and escalation owner.
A location, branch, or unit that belongs under a parent organization.
Example: A child location can have its own staff, customers, tickets, dashboards, and local settings.
A button that removes search or filter choices so the user can start again.
Example: A clear-all button can remove active filters from a lesson list.
An account meant for an outside customer or business contact using a limited portal.
Example: A client account may view its own requests without opening the internal staff workspace.
A clear route that lets a client take the next allowed action without seeing internal workflow noise.
Example: A client action path can guide a customer to upload a file, answer a question, approve a quote, or send a reply.
A limited customer-facing area where clients can view or update their own business records.
Example: A client portal may show request status, messages, files, and approved updates.
An ordered client-facing view of meaningful updates, milestones, and status changes.
Example: A client timeline can show request received, review complete, approval needed, scheduled, and completed.
A screen or section intended for a client, requester, or customer rather than internal staff.
Example: A client-facing view can show approved request status, messages, files, and next steps.
The final workflow state that shows work is complete, reviewed, and no longer active.
Example: A closeout state can require completion notes before the request leaves the active queue.
A short explanation of what was resolved, what changed, and what the user should know after support work ends.
Example: A closure note can tell a client that access was restored and no further action is needed.
A condition that must be met before a workflow can be marked finished.
Example: A closure rule can require completed work notes and approved proof before closeout.
A cue that communicates meaning without depending on color alone.
Example: An error message can use text and an icon instead of only red color.
A workflow event that should create a customer update, staff reminder, or portal message.
Example: A status change to scheduled can trigger a customer-facing appointment update.
A safe follow-up action that repairs or balances a result that cannot be directly reversed.
Example: A compensating action can create a correction note when an already-sent customer message cannot be unsent.
The clear set of conditions that says when work is ready enough to present or hand off.
Example: A completion standard can require working core paths, acceptance checks, review notes, and a clear project story.
A planning habit where repeated interface pieces are named and reused intentionally.
Example: A dashboard can reuse the same summary-card pattern for lessons, progress, and homework.
A deliberate version of a reusable component that changes for a known reason such as size, state, or context.
Example: A compact card variation can use the same structure as the full card while changing only the details that belong to the compact use case.
An action that only happens when a rule or situation is true.
Example: A high-priority request can trigger a conditional action that routes it to a review queue.
A mismatch where settings differ across environments in a way the team does not understand or expect.
Example: Config drift can make a dashboard work during review but behave differently when real users open it.
A difference between expected settings and the settings actually used in an environment.
Example: A config mismatch can make login, static files, emails, storage, or protected pages behave differently than expected.
A changeable value that affects how software behaves without changing the main application code.
Example: A config setting can choose whether a feature is unavailable, preview-only, or live.
A message or visible cue that tells the user an action worked.
Example: After a note is saved, confirmation feedback can say Internal note added.
A required review step before a sensitive or multi-record action is applied.
Example: A confirmation gate should show how many records will change before staff continue.
A validation step that compares related fields or records to make sure they still agree with each other.
Example: A consistency check can verify that a completed job also has a stored completion time and matching owner history.
The state where related product screens, website copy, and launch messaging describe the same thing consistently.
Example: Content parity helps a lesson card, article page, and launch note use the same title, status, and promise.
A link or action shown near the place where it is useful for the current workflow.
Example: A ticket detail page can show a shortcut to reassign the owner or open the customer record.
A mismatch that appears when a caller and backend boundary no longer agree about required inputs, outputs, or behavior.
Example: Contract drift can happen when the backend renames a response field but the dashboard still expects the old name.
The trace of messages, replies, and updates that explain what has happened so far.
Example: Conversation history helps a new staff member understand a request without asking the client to repeat everything.
The planned route a lead follows from first interest toward a clear outcome.
Example: A conversion path can move from inquiry to qualification, proposal, follow-up, and won or lost outcome.
A difference between two user-facing messages that should agree.
Example: A copy mismatch happens when a page says a feature is available but the app labels it unavailable.
A user action that adds a new record with the information needed to start useful work.
Example: Submitting a service request form is a create action.
The part of a workflow where the user adds a new item or changes an existing one.
Example: A profile form can show a create state for a new profile or an edit state for an existing profile.
A workflow path that moves a location-specific issue to a parent or regional role when broader oversight is needed.
Example: A cross-location escalation can send repeated branch delays to a regional manager for review.
A view that summarizes or compares information across multiple locations.
Example: A cross-location view can show total tickets, sales, subscribers, or workload across all branches.
An unsafe exposure where one tenant can see or act on another tenant's private information.
Example: A cross-tenant leak can happen when a dashboard query forgets to filter by account or organization.
View or service logic that handles extra workflow behavior instead of only saving form fields.
Example: A custom handler can validate an assignment action, update status, and write a history note together.
A designed flow that adds business rules, decisions, or steps beyond a direct form-to-model save.
Example: A request approval path may need a custom workflow when it assigns owners and changes status after review.
A message that gives useful customer context without exposing staff-only details, private reasons, or confusing internal labels.
Example: A customer-safe message can say that a request is waiting on approval instead of showing staff-only review notes.
A screen or area that summarizes important information and gives people quick paths into common tasks.
Example: A support dashboard can show open tickets, urgent items, and the next action staff should take.
The first dashboard view a user sees when they enter a portal or operational workspace.
Example: A dashboard home surface can prioritize active requests, missing documents, recent updates, and next actions.
A specific number, count, rate, or status summary shown on a dashboard because it supports a real decision.
Example: Open escalations this week can be a dashboard metric when staff use it to plan follow-up work.
A named area of a dashboard that groups related information or actions.
Example: A dashboard section might group today's tickets, sales follow-ups, subscriber changes, or location alerts.
A compact piece of information that helps a user understand priority, status, risk, or next action.
Example: A dashboard signal can show overdue requests, missing documents, blocked approvals, or open support items.
The deliberate order dashboard panels follow when a wider multi-column layout collapses into a single vertical flow.
Example: A stronger dashboard stack order can place summary status, active work, and next actions before deeper reporting panels.
The route a backend feature uses to fetch, filter, join, or summarize the records it needs.
Example: A data access path can move from a customer record to active jobs and then to recent completion notes.
A review that checks whether records, queries, dashboards, and actions stay inside the intended tenant boundary.
Example: A data boundary review can verify that every portal list filters by account before launch.
The condition where records stay complete, consistent, and believable across the workflow.
Example: Data integrity is stronger when a request cannot save conflicting status and ownership information.
The practice of turning similar incoming values into a consistent format or category.
Example: Normalizing urgent, URGENT, and high priority into one priority value makes routing easier to review.
A structured display that organizes many related items into rows and columns.
Example: A ticket list can use a data table to show title, status, owner, and updated time.
A start and end period used to limit records in a report or summary.
Example: A date range can show support requests created between Monday and Friday.
A place in a flow where the person is left without a clear next step.
Example: A thank-you screen with no button, link, or instruction can become a dead end.
A small pause point used to confirm what has happened before checking the next step.
Example: After clicking Save, a debug checkpoint can ask whether the click ran and whether the message changed.
A dashboard card that combines a useful number with context that helps someone choose the next step.
Example: A decision card might show overdue urgent requests and link staff back to the filtered queue.
A step where a choice or condition changes what should happen next.
Example: If a request is urgent, the next step may be different from a normal request.
The reason behind a meaningful project choice.
Example: A decision rationale can explain why a simple table view was chosen before a complex chart.
A note that captures an important choice, the reason for it, and the expected effect.
Example: A decision record can explain why a preview label stays visible until assignment review is complete.
A report detail that helps a team choose what to do next.
Example: A spike in overdue tickets can be a decision signal to add review time.
A screen, report, or summary that helps staff make a practical operational decision.
Example: A manager dashboard can show overdue requests and blocked work so staff know where to act first.
A backend trigger that runs later based on time, schedule, or queue conditions instead of immediately in the original request.
Example: A delayed trigger can send a reminder tomorrow if the request is still waiting for review.
A clear confirmation step before a risky removal action finishes.
Example: A delete confirmation can ask the user to confirm before a draft request is removed.
A real limit that affects what can be built, reviewed, or handed off safely.
Example: A delivery constraint may include time, available data, staff review capacity, or a required approval step.
The path from project planning through build, review, release readiness, and presentation.
Example: A delivery cycle can move from scope to requirements, wireframes, build, QA, handoff, and final presentation.
The visible movement of work through useful states that help staff and customers understand what changed.
Example: A progress note can show that a request moved from scheduled to in progress after a technician started work.
Something a software feature needs in order to work, such as a setting, asset, service, library, or database change.
Example: A missing dependency can make a dashboard fail even when the page template looks correct.
The habit of preparing, checking, and releasing changes through a controlled process instead of rushing to live use.
Example: Deploy discipline includes checks, backups, migration review, and a clear rollback plan.
The state of being prepared to move a Django app into a live or live-like environment safely.
Example: Deployment readiness means checking settings, migrations, assets, dependencies, and verification steps before handoff.
One planned action in the process of moving reviewed software toward live use.
Example: A deployment step can include confirming content readiness before a launch starts.
A named reusable value for interface decisions like color, spacing, radius, or typography.
Example: A token can define the primary accent color instead of repeating the same hex value everywhere.
A screen that shows the important information, status, owner, and actions for one record.
Example: A ticket detail view can show the issue, customer, status, owner, notes, and next button.
A button or action that is unavailable until the user meets a requirement.
Example: A submit button may stay disabled until required fields are complete.
A clear line that explains which responsibility belongs inside one Django app and what should stay outside it.
Example: A billing app can own invoices while an accounts app owns user identity and sign-in behavior.
A short planning view that names each Django app and the product responsibility it owns.
Example: A responsibility map can show that the queue app owns assignment state while the notes app owns staff comments.
A Django mechanism that lets code respond when certain model or framework events happen.
Example: A post-save signal can notice that a record changed and start a small follow-up workflow.
A portal area where users can find, upload, review, and track files tied to the right account or workflow.
Example: A document center can organize proposals, contracts, approvals, receipts, and client uploads.
A rule that controls who can view, upload, replace, approve, or delete a portal document.
Example: Document permissions can let clients upload files while only staff can approve or archive them.
A route for generated documents that need human review before they are stored, sent, or used.
Example: A document review path can hold a proof packet when required completion evidence is missing.
A reusable structure that defines what a generated document should include.
Example: A document template can include customer details, service scope, completion notes, and approval lines.
A rule that should remain true for a product concept no matter which view or workflow changes it.
Example: An invoice total should not become negative unless the product has a clear credit or refund rule.
The way a Django product organizes its main business concepts, records, and relationships.
Example: A service platform domain structure may separate customers, tickets, visits, invoices, and staff notes.
A partially completed product record that is saved before the final review or submit step.
Example: A draft application can hold form answers while the user moves through several screens.
The date or time by which a task, request, or workflow step should be handled.
Example: A due date can tell the support owner when a customer reply is expected.
A validation check that helps prevent the same record from being created twice.
Example: A duplicate check can warn staff when a customer already has an open request for the same issue.
The chance that a queued job or reminder path will run the same meaningful action more than once by mistake.
Example: Duplicate execution risk rises when retries can create extra follow-up records instead of checking for the first result.
A rule that stops the system from creating the same important record or action more than once by accident.
Example: A duplicate guard can block a second dispatch record when the first dispatch is already active.
A safety check that stops repeated automation runs from creating extra messages, tasks, or records.
Example: Duplicate prevention can avoid sending the same customer reminder twice.
The chance that the same information is entered or changed in more than one place without clear rules.
Example: Duplicate risk grows when staff copy a customer status into two tools by hand.
A role-specific staff area for active work, queues, assignments, blockers, and next actions.
Example: An employee workspace can show assigned ticket cards, missing context, and the next safe action for each item.
The message or screen shown when a list has nothing to display.
Example: A filtered list can say, 'No open tickets match this filter.'
Helpful copy or action shown when a dashboard area has no records yet.
Example: An empty state can explain that no files are waiting and link to the upload instructions.
A check that confirms whether the current user has a specific permission, plan, or access right.
Example: An entitlement check can confirm that a student has Academy Plus before opening a protected lesson.
A clear rule that connects a plan, purchase, role, or status to allowed access.
Example: An entitlement rule can allow active Plus members to open a specialty lesson after prerequisites are complete.
The place where a person begins a flow.
Example: A dashboard button can be the entry point for opening a support ticket.
A configuration value that can differ between local, staging, and production environments.
Example: A production email backend may use a different environment setting than a local development mailbox.
A named value supplied by the surrounding environment instead of being written directly into application code.
Example: An app can read an environment variable to choose a safe setting for the current environment.
The clear next step users or staff can take after a product action fails.
Example: A failed upload can offer retry, safe reset, or staff follow-up instead of a blank error.
A response that explains why the action could not be completed.
Example: An error response can say Choose an owner before assigning this ticket.
A clear message that explains what went wrong, what remains safe, and what the user should do next.
Example: An error-state message can say that a file upload failed and the document was not changed.
A route that sends higher-risk or higher-priority work to a responsible reviewer or owner.
Example: A payment dispute can use an escalation path instead of a standard support queue.
The condition that makes a workflow move from ordinary follow-up to a higher-priority owner or queue.
Example: An escalation threshold can trigger when a request stays unresolved past its promised response time.
A ticket that needs higher attention because normal ownership, timing, or priority handling is not enough.
Example: An overdue high-priority refund request may become an escalation ticket for a manager.
The code or planned response that runs after a specific event trigger happens.
Example: A button's event handler can show a saved message after the user clicks.
The order in which a user action, interface update, and visible feedback should happen during one interaction.
Example: A safe event sequence might be click Apply filter, update the result list, then refresh the count and empty-state message.
A label that helps people understand how urgent or important an automation event is.
Example: A failed customer notification may use higher severity than a skipped optional reminder.
The ordered sequence of backend events used to reconstruct what happened across one workflow.
Example: An event timeline makes it easier to understand whether a request failed before or after reassignment.
The user action or browser action that starts an interface response.
Example: Clicking a Save button or typing in a search field can be an event trigger.
A screen, note, checklist, or sample that supports the project story with visible proof.
Example: A QA checklist, wireframe, screenshot, or handoff note can be an evidence artifact.
A list of proof points used to confirm that portal screens, permissions, content, and workflows have been reviewed.
Example: An evidence checklist can include QA notes, accessibility checks, trust signals, and permission checks.
A short explanation attached to proof or supporting material.
Example: An evidence note can say uploaded photo shows completed installation.
A short explanation of what review evidence shows that a screen or flow is strong enough to share or hand off.
Example: An evidence summary can mention scan clarity, keyboard flow, error recovery, and stable updates after key actions.
The backend history that shows when a proof item was uploaded, reviewed, replaced, or retained over time.
Example: An evidence trace helps the team explain whether the current file is original proof or a later replacement.
A work item that does not fit the normal process and needs a defined review or handling rule.
Example: A request missing required customer approval can become an exception case before scheduling.
The process of identifying, reviewing, routing, and resolving work that does not follow the normal path.
Example: Exception management can route a failed upload, overdue approval, or blocked request to an administrator.
A short review note that explains why a work item needs special handling and what should happen next.
Example: An exception note can explain that customer approval is missing and billing should wait before invoicing.
A safe alternate route for work that cannot follow the normal automation rule.
Example: An exception path can pause a request with missing location details for staff review.
A structured check of unusual, blocked, overdue, or risky work before an administrator intervenes.
Example: Exception review can separate a normal delay from a request that needs escalation.
What the screen is supposed to do after a specific user action.
Example: After the user clears a search, the expected behavior is that the full item list returns.
The result that should happen when a test runs the correct action under the right conditions.
Example: An expected outcome might be a new status, a redirect, an error message, or a saved record.
An account whose membership period or access window has ended.
Example: An expired account may need restricted access, renewal messaging, support review, or retention follow-up.
The structured shape used when data leaves the app for review or handoff.
Example: CSV can be an export format for a list of completed service requests.
A rule that decides who can download or move structured data out of the app.
Example: Only an account owner may have export permission for customer records.
The review discipline that checks whether exported backend data stays scoped, accurate, and explainable outside the app.
Example: Export safety matters when a CSV leaves the app and could expose the wrong records to the wrong audience.
A simplified status shown to customers or clients that may differ from detailed staff workflow states.
Example: A customer may see in review while staff see pending manager approval.
The route a record follows when work must continue in a tool outside the current app.
Example: An external tool path can open the CRM record that belongs to a selected lead.
A clear sign that a review step did not meet the expected behavior.
Example: A fail condition can say the saved owner disappears after refresh or appears to the wrong role.
A scenario that should be rejected, blocked, or handled with a clear error.
Example: A failing case can confirm that a student without the required plan cannot open a protected player.
A safety approach that prevents one automation failure from spreading into more records or systems.
Example: Failure containment can pause a broken integration before it sends more incorrect updates.
The route the system should follow when a normal backend action cannot finish successfully.
Example: A failure path may keep the record unchanged and log the reason instead of silently continuing.
A repeated kind of automation problem that suggests a rule, connection, or workflow needs review.
Example: A repeated missing-owner failure can show that intake routing needs a stronger fallback owner.
The planned path a backend workflow follows after an important action fails, stops midway, or produces an unsafe result.
Example: Failure recovery can keep a payment review in pending status and record the reason instead of pretending it completed.
A documented path for detecting, pausing, repairing, and reviewing automation failures.
Example: A failure recovery plan can tell staff what to do when a CRM handoff fails three times.
The clue in backend history that shows a step did not finish as expected and needs investigation.
Example: A failure signal may be a retry event, a missing follow-up, or a logged mismatch after save.
The person or team responsible when automation cannot confidently choose the normal route.
Example: A fallback owner can review ambiguous intake records before automation continues.
A Django view that has collected too much workflow, query, validation, or side-effect logic.
Example: A fat view may create records, send messages, update status, and calculate reports all in one request handler.
A user-facing statement that says what a product, page, or feature can do.
Example: A feature claim should only promise behavior that the app actually supports.
A clear rule that decides whether a user can see or use a specific feature.
Example: A feature gate can check plan, role, enrollment, or preview rules before showing a dashboard tool.
The decision about which feedback message needs the strongest position or visibility first when several messages compete for attention.
Example: An urgent error message usually needs stronger feedback priority than a quiet success note elsewhere on the screen.
A limit that keeps a field within an allowed format, range, or set of values.
Example: A priority field can be constrained to Low, Medium, High, or Urgent.
A small set of related form fields that are intentionally kept together so the person can understand one part of the form at a time.
Example: A field group might keep address lines, city, state, and zip code together in one clear section.
The clear purpose of an input field and what the person should enter there.
Example: A service date field should make it clear whether the user should enter a preferred date or a required deadline.
A file, image, document, or uploaded item that supports what happened in the workflow and needs a trustworthy backend path.
Example: A signed work photo can act as file evidence for a completed field-service request.
A label that explains whether a document is waiting, accepted, rejected, expired, or needs replacement.
Example: A file review status can tell a client that an uploaded insurance document needs replacement.
Rules that decide who can see or use an uploaded file.
Example: An internal invoice attachment may be visible to staff but hidden from the client portal.
An option that narrows a list to show only matching items.
Example: A filter option can show only open support tickets.
A grouped area that lets a person narrow a list by categories or states.
Example: A homework list can use a filter panel for status, track, and assigned reviewer.
A count of records after narrowing the QuerySet to a useful condition.
Example: A filtered count can show only requests with a status of Waiting.
A summary that changes based on selected criteria such as status, owner, or date.
Example: A filtered summary can show only overdue high-priority tickets for one team.
The closing package of notes, evidence, and next steps that lets another reviewer understand the product work.
Example: A final handoff can include release cautions, testing notes, support gaps, and follow-up recommendations.
The organized explanation of finished work, evidence, outcomes, and lessons learned.
Example: A final presentation can show the capstone goal, key screens, QA evidence, and next-step recommendation.
Small prepared records used to make a test scenario realistic and repeatable.
Example: Fixture data might include a staff user, client user, open request, and active membership plan.
The sequence keyboard focus follows as a user moves through links, buttons, inputs, and actions.
Example: A form should move from the first field to the next field, then to the submit button in a sensible order.
The moment an interface returns keyboard focus to a sensible place after a panel closes, a step completes, or a temporary element disappears.
Example: After closing a help panel, focus recovery should return the user to the button that opened it or the next meaningful interface step.
The visible sign that a link, button, or form field is currently selected for keyboard interaction.
Example: A button with a clear outline shows where keyboard focus is before the user presses Enter.
A focused list of leads or records that need a next contact, reminder, reply, or decision.
Example: A follow-up queue helps staff avoid losing leads after the first conversation.
The current condition that tells automation whether a reminder, check-in, or escalation is still needed.
Example: Waiting on customer, owner assigned, and resolved can be follow-up states.
A condition that starts a follow-up action or reminder.
Example: A follow-up trigger can run when a ticket has been waiting for two days.
The planned timing range when a reminder, check-in, or next action should happen.
Example: A follow-up window may send a status check two business days after a request is completed.
The practice of using saved history, log entries, and event order to explain backend problems after they happen.
Example: Forensic debugging uses the timeline to reconstruct the real path the workflow followed.
A small group of labels, inputs, help text, and feedback that belong together.
Example: A contact form group can include an email label, input, and guidance text.
A structured set of related fields, labels, helper text, validation rules, and feedback patterns that work together in one interface flow.
Example: A request form system can group contact details, service details, and confirmation notes so the person is not guessing where to look next.
Rules that check submitted form values before a record is saved.
Example: Form validation can require a request type and a useful description before creating a service request.
A guided sequence of forms that breaks one larger product task into smaller steps.
Example: A quote request wizard can ask for contact information first, service details second, and review confirmation last.
A record change that happens directly from submitted form values.
Example: Editing a phone number is a form-driven update when the value is saved directly to the profile.
A message near the whole form that summarizes why the form cannot be submitted yet.
Example: A form-level error can say, 'Fix the highlighted fields before submitting.'
A portal view that shows information for one location inside a larger franchise or multi-location account structure.
Example: A franchise location view can show tickets, documents, and metrics for one branch without exposing another branch.
A specific business unit, branch, or location that operates under a larger brand or parent structure.
Example: A franchise unit may need its own staff, clients, tickets, reports, and local settings.
A structured check of what people see and use in the browser, including content, layout, behavior, and feedback.
Example: A frontend review asks whether the page is readable, usable with a keyboard, and clear after an error.
A feature that is available only when the user's plan, role, or entitlement allows it.
Example: A premium export button can be a gated feature if only members with full access can run it.
A document created from workflow data, templates, and automation rules.
Example: A generated document can produce a service summary after staff approve the request details.
A safety review that confirms required fields are present before a document is generated.
Example: A generation check can pause invoice generation when the approved total is missing.
A temporary access state that gives a user limited time or limited rights before access changes fully.
Example: A grace state can let a recently expired customer download invoices while blocking new premium work.
A summary where records are organized by a shared field or condition.
Example: A grouped result can show request counts by status or by assignee.
A field the backend uses to protect an important workflow rule by storing a required note, reason, or linked value.
Example: A guardrail field can store the cancel reason that keeps a closed request history understandable later.
A check that confirms the next system or owner received enough context to continue.
Example: A handoff confirmation can record that a CRM task was created for the assigned owner.
A clear note that gives the next person enough context to continue the work without guessing.
Example: A handoff note can include scope, current state, blockers, files or screens reviewed, and next steps.
A concise set of materials that helps another reviewer understand what should be built, tested, launched, or revised next.
Example: A handoff package can include scope, status model, access boundaries, report definitions, rollout plan, and open questions.
The required information passed during a handoff so the next system or owner can act safely.
Example: A handoff payload may include customer name, request type, priority, owner, and consent status.
The place where responsibility or data passes from one user, screen, or service step to another.
Example: The handoff point from intake to dispatcher needs a clear owner and a complete status.
A clear condition that explains when work moves from one team, owner, or queue to another.
Example: A handoff rule can move a completed field visit to billing only after completion notes are present.
A state that shows work is moving from one person, role, or step to another.
Example: A request can be in handoff when intake sends it to review.
A small check that helps confirm whether an important product system or dependency appears available.
Example: A health check can confirm that the application can reach the database and load core pages.
A visible sign that helps the team judge whether software is working normally after launch.
Example: A health signal can be successful login, completed form submission, low error rate, or normal queue activity.
Short supporting copy near a field that explains format, expectation, or consequences before the person makes a mistake.
Example: Helpful helper text can say that a phone number is only used for project updates, which reduces hesitation.
An ordered record of important changes, notes, status updates, and ownership movement.
Example: A history stream can show that a request moved from assigned to waiting on customer after a follow-up message.
A point where a person reviews, approves, or corrects work before automation continues.
Example: A refund request may need a human checkpoint before a customer message is sent.
An action designed so running it more than once does not create duplicate or conflicting results.
Example: Creating one reminder task per request is safer when the action checks whether the task already exists.
A task that can safely run more than once without creating duplicate or conflicting product results.
Example: A reminder task can check whether a reminder was already sent before sending another one.
A workflow designed so a repeated job run does not create extra records or contradictory state after the first correct result.
Example: An idempotent workflow lets a reminder retry safely without duplicating the same follow-up task.
A low-level build choice that may not belong in a beginner requirement unless it affects expected behavior.
Example: Choosing a field label is useful requirement detail; naming a private database technique is usually too deep for the handoff.
Visible proof that a planned product behavior was actually built and can be reviewed.
Example: Implementation evidence can include a working page, seeded lesson, test result, or support record.
Information that comes back from another tool into the current system.
Example: An inbound update can show that a CRM lead changed to won after the sales team followed up.
A short operational record that explains what failed, what was affected, and what recovery action was taken.
Example: An incident note can explain that exports were paused while the reporting query was reviewed.
A record that looks active or valid on the screen but is missing data the backend still requires.
Example: An incomplete record may show approved while still missing the approval reason that later audits need.
A field prepared for faster lookup when queries often filter or sort by that value.
Example: An indexed field can help a support queue find open requests by status more quickly.
The amount of useful information shown in a screen area without making the screen feel overloaded.
Example: A dashboard can show more details when headings, spacing, and groups help people scan calmly.
The first workflow state assigned when a new record is created.
Example: A submitted service request may begin with an initial status of New or Needs review.
Feedback shown close to the field that needs attention.
Example: A message under an email field can say, 'Add a valid email address.'
The step of removing confusing, incomplete, duplicate, or unusable details before automation relies on them.
Example: Input cleanup can trim extra spaces and flag a missing customer phone number before a routing rule runs.
A message near or around an input that helps the user fix or confirm entered information.
Example: Input feedback can say Enter a valid email before the request can be submitted.
A form that collects the information needed to start a request or workflow.
Example: A service request intake form may ask for contact details, request type, priority, and a short description.
The part of business software that captures a new request with enough detail for staff to review it.
Example: An intake system can collect customer contact, request source, service type, urgency, and notes.
The path that turns a new request into a usable saved record.
Example: A service intake workflow can collect customer details, issue type, priority, and contact information.
The line that defines which work stays in one system and which work moves to another connected tool.
Example: An integration boundary can keep support tickets in the service app while sales history lives in the CRM.
A structured check of how automated work moves between systems, owners, queues, and recovery paths.
Example: An integration review can confirm that a website request, CRM task, and staff follow-up stay aligned.
A test that checks whether connected parts of the product work together through a realistic path.
Example: An integration test can submit a form, follow a redirect, and confirm that the page shows the saved record.
A step-by-step path of what the user did and how the screen responded.
Example: An interaction trace can list click filter, update count, show matching items.
A careful review of a screen to find clarity, accessibility, layout, and interaction issues before making changes.
Example: A staff member audits a form screen and notes that the main action is unclear on mobile.
A staff-only note attached to a record that should not be shown to clients or students.
Example: An internal comment can explain why a ticket was reassigned without exposing staff-only details.
A staff-only note that records useful workflow context without being shown to customers or students.
Example: An internal note can explain why a request was escalated without exposing private staff discussion.
Information that should remain visible only to staff or other authorized internal users.
Example: Internal-only data can include staff assignment notes, private review comments, or internal priority decisions.
A safe route for a manager or administrator to step into stalled or risky work.
Example: An intervention path can let a manager reassign an overdue item with a required reason note.
Information that does not meet the rule needed for the record or workflow step.
Example: A blank required phone number can be an invalid entry on a callback request.
The repeatable steps that show how a problem happened so another person can see it too.
Example: Issue reproduction can list the account role, starting screen, clicked action, entered data, and unexpected result.
A saved note of when a scheduled job ran, what it tried, and what happened.
Example: A job run record can show that a reminder job skipped completed requests.
The timing rule that decides when a backend job should run again or wait until later.
Example: A job schedule can run a reminder every morning until the follow-up is completed.
The order and rhythm a keyboard user experiences while moving through links, menus, actions, and return paths in an interface.
Example: A good keyboard flow lets a student move from the track menu into the lesson action area without getting lost in repeated links.
The current interactive place a keyboard user is using on a screen.
Example: A focused Save button should be visible before the user presses Enter.
A meaningful app page area, such as navigation, main content, search, or complementary support content.
Example: A dashboard can separate its navigation region from its main work area.
A problem that should be fixed before a feature or content area is treated as ready for public use.
Example: A broken signup link or misleading feature claim can be a launch blocker.
The planned period when a team makes a launch change and watches the result closely.
Example: A launch window gives the team time to verify the change and respond if something breaks.
A rough arrangement of screen regions used to test whether the structure supports the user goal.
Example: A layout draft can place filters above a ticket list and the primary action near the record summary.
A consistent spacing and grouping pattern that helps repeated interface pieces feel organized.
Example: Cards with matching padding and aligned labels create a calmer layout rhythm.
A current label that explains the condition or attention need of a lead.
Example: A lead status can show waiting on reply, needs follow-up, not qualified, or ready for proposal.
A staff workflow that gives each role only the access needed to do its part of the job.
Example: A billing reviewer can approve invoice corrections without receiving access to unrelated support-note tools.
A practical takeaway from the work that can improve future projects.
Example: A lesson learned might explain that clearer empty states reduced support confusion.
A secondary path the record can follow when a special condition, exception, or recovery step appears.
Example: A lifecycle branch can handle canceled work differently from delayed work.
A written view of the states, transitions, and exception paths a record can follow.
Example: A lifecycle map can show how a request moves from intake to review to approval to completion.
A managed release to a smaller group before a workflow reaches everyone who may eventually use it.
Example: A limited rollout can start with one team before expanding to every location.
A common app pattern where a user starts from a list and opens one item to see more detail.
Example: A lesson archive can lead to one lesson detail page for deeper reading.
A dashboard area that reflects current saved records instead of a hardcoded sample value.
Example: A live data block can update when requests are created, assigned, or closed.
The way a backend feature retrieves related data, such as one focused query or many repeated follow-up queries.
Example: A loading pattern can become slow when each row in a list triggers its own extra lookup.
A visible state that tells the user the software is working on an action.
Example: A Save button can show Saving while the request is being handled.
The boundary that decides which records, users, actions, or reports belong to a specific location.
Example: Location scope helps staff see only the records connected to their branch unless they have broader access.
A safe interface option that lets authorized users move between allowed locations while keeping the active location clear.
Example: A location switcher can let a regional manager choose North, South, or Downtown before reviewing tickets.
A permission rule that limits visibility or actions to specific locations within a larger account structure.
Example: A location-scoped permission can let one branch manager see only their own team's documents.
A saved note in the backend timeline that records one meaningful event, action, or failure signal.
Example: A log entry can show that a reminder job ran, failed, or retried with a visible reason.
A clear way for people to continue or repair work when automation should pause or cannot finish safely.
Example: A manual fallback can route a failed CRM update to a staff review queue.
A staff-facing place where uncertain or failed backend records wait for human review instead of disappearing.
Example: A manual review queue can hold requests whose automated approval failed and needs a supervisor decision.
A named access level that defines what a customer, learner, or account can use.
Example: A Plus plan may include specialty lessons while a free plan may include public previews only.
The current membership condition that affects access, billing-adjacent handling, or staff follow-up.
Example: Membership status can include active, paused, trial, expired, canceled, or needs attention.
The way related navigation links are organized so users can scan destinations more easily.
Example: A dashboard can group Tickets, Clients, Reports, and Settings into separate menu areas.
The planned timing or frequency for updates so customers know when to expect communication.
Example: A service workflow may send updates at intake, scheduling, arrival, delay, and closeout.
The person, team, or customer who should receive a workflow message.
Example: A message recipient might be the assigned owner, the customer, or the operations lead.
A review condition that prevents an automated message from being sent with missing, stale, or risky context.
Example: A message safety check can pause a reminder if the customer email or appointment time is missing.
The rule that decides who can see a comment, reply, or update.
Example: Message visibility keeps staff-only notes separate from client-visible replies.
A plain explanation of what a metric counts, where the data comes from, and why it matters.
Example: A closeout rate definition should explain which requests count as closed during the reporting period.
A review that confirms database schema changes are present, expected, and safe to apply.
Example: A migration check helps prevent a model change from reaching a live app without the matching database update.
A check of database schema changes before release so product data is not put at unnecessary risk.
Example: A migration review can confirm whether a new required field has a safe default or rollout plan.
A client-safe update tied to a meaningful progress point rather than every internal action.
Example: A milestone update can tell the client that scheduling is confirmed without exposing staff assignment notes.
The connected sequence of screens and actions that make a focused mini app feel coherent.
Example: A mini app flow can connect intake, dashboard, detail, comments, status updates, and summary views.
A repeatable way to shape Django models for a common product need without copying blindly.
Example: A status-history model pattern can help several workflows record state changes consistently.
A test that checks model rules, relationships, defaults, and small domain behavior.
Example: A model test can confirm that an overdue ticket helper returns true after the due date passes.
A Django form pattern that builds form fields from a model so a saved record can be created or edited with less repeated setup.
Example: A simple contact request can use a ModelForm when the form maps cleanly to the request model.
A simple outline of the main areas or modules that belong in a larger dashboard system.
Example: A module map can show sections for metrics, work queues, sales, subscribers, tickets, reports, and manager review.
A record that belongs to, references, or can be filtered by one or more business locations.
Example: A multi-location record should make its location relationship clear for reporting and access rules.
A workflow split into more than one screen, decision, or action because the process needs staged handling.
Example: A service request may use a multi-step flow for intake, staff review, assignment, and closeout.
A product flow that requires several connected steps before the final record is ready to save or review.
Example: A service intake wizard may collect customer details, job details, scheduling preference, and confirmation across several steps.
A shared work list where more than one team can review, claim, route, or complete related work.
Example: A service queue may include dispatch, field operations, billing, and manager review items.
A rule that keeps one customer, account, organization, or workspace from seeing another tenant's records.
Example: A multi-tenant boundary prevents a client from seeing requests, files, or dashboard data for another company.
A repeated database lookup pattern where a page loads one main list and then makes extra lookups for each row.
Example: A ticket list can create an N plus one query pattern if each row separately looks up the assigned staff member.
A performance problem where the backend runs one query for a list and then another query for each item in that list.
Example: N plus one risk appears when a job list loads owners one row at a time instead of preparing them together.
Too many links, labels, or repeated destinations competing for attention in a portal interface.
Example: Navigation clutter happens when clients, employees, and administrators all see every possible link.
A labeled set of related portal links that helps users find the right area without scanning every feature.
Example: A navigation group can separate Client updates, Documents, Work queue, and Admin review links.
The moment a screen gives the user a clear next place to go after an action.
Example: After saving a form, a navigation handoff can return the user to the detail page.
The set of destinations a user type can see and use inside a system.
Example: A staff navigation scope can include ticket queues while a subscriber scope focuses on account and billing pages.
A short explanation that tells the user what action, wait, or review comes after the current status.
Example: A next-step message can say, Please approve the estimate before scheduling can continue.
A clear instruction for the next useful action after a handoff or status update.
Example: A next-step note can tell the reviewer to check the lesson player, assignment form, and article card.
A helpful message shown when search or filters leave no matching items.
Example: A no-results state can say, 'No lessons match that search. Clear the search and try again.'
The decision about which notes are staff-only, customer-facing, or safe for a simpler public update.
Example: A repair delay can have an internal reason while the customer sees a simple status update.
A meaningful workflow moment that may need to alert the right person.
Example: A notification event can happen when a high-priority request is assigned.
A clear condition that decides when an automated message should be sent and to whom.
Example: A notification rule can send a reminder only after the appointment time and contact method are confirmed.
The ability to understand what a product is doing through logs, metrics, health signals, and support evidence.
Example: Observability can help staff see whether failed exports are isolated or part of a wider issue.
A menu that is hidden off screen until the user opens it, often on smaller screens.
Example: A mobile dashboard can move sidebar links into an off-canvas menu.
A planned review point that helps a team catch missing, stalled, or risky work.
Example: A manager can use an operational checkpoint to review overdue service requests each morning.
A practical review of whether a software plan supports the business workflow, users, records, risks, and follow-up needs.
Example: An operational design review can check whether routing, permissions, reports, customer updates, and rollout support work together.
A plain-language path that shows how work moves between dashboard modules and supporting screens.
Example: An operational flow map can move from a metric card to a queue, then to a ticket detail and follow-up step.
A measured value that helps staff understand workflow health, speed, volume, or quality.
Example: Average time in triage can show whether incoming work is getting reviewed quickly enough.
The ability to understand workflow health by reviewing events, counts, failures, and recent activity.
Example: Operational observability can help staff notice that CRM handoffs are failing after a connection change.
The path staff follow to inspect, filter, update, and confirm product records during day-to-day operations.
Example: A review path can start from filtered tickets, open a detail screen, check readonly context, and save a staff note.
A practical rule, check, or fallback that helps staff recover safely when a backend workflow has trouble.
Example: An operational safeguard can alert support when a reminder job fails three times.
A safe helper that reduces repetitive staff work without hiding important decisions.
Example: An operational shortcut can save time when it still explains the records, action, and result.
A practical plan that shows the dashboard modules, user roles, routes, and follow-up paths a working operations system needs.
Example: An operations dashboard blueprint can combine metrics, queues, tickets, memberships, locations, and reports into one coherent plan.
A staff-facing area where real product work is reviewed, updated, or coordinated.
Example: A service operations surface can let staff review requests, update status, and inspect recent activity.
A field that can help but is not required for the workflow to continue.
Example: A preferred callback time can be optional if the request can still be reviewed without it.
Helpful information a user may provide, but the form can still work without it.
Example: A photo note might be optional if the request can be submitted with a written description.
A planned movement of information from the current system into another tool.
Example: An outbound handoff can send a new qualified lead from a portal into a CRM.
A plain explanation of what changed or became possible after the work was completed.
Example: An outcome statement can say staff can now review open tickets by owner and priority.
The number of items that have passed a promised, expected, or useful response time.
Example: An overdue count can help staff decide what needs follow-up first.
A workflow state showing that an item has passed its expected action time.
Example: A request can enter an overdue state if no one follows up before the due date.
A task that has passed its expected due time or follow-up time.
Example: An overdue task should be easy to find so the team can decide what to handle next.
A ticket that has passed its expected response or resolution time.
Example: An overdue ticket should be visible enough that the team knows follow-up is late.
A required explanation recorded when an administrator changes a normal workflow decision or status.
Example: An override note can explain why a manager reopened a closed request for additional review.
A dashboard area that helps an approved reviewer see status, workload, risk, or follow-up needs across a system.
Example: An oversight panel can show overdue tickets, high-priority requests, stalled pipeline stages, and branch-level workload.
A rule that separates what one owner, manager, location, or staff group is allowed to see or change.
Example: Owner boundaries keep one location from changing another location's records unless that access is intended.
The part of a record that names who is responsible for the next action.
Example: A support ticket owner field can show which teammate should respond next.
A managed handoff that moves responsibility for a record or task from one owner to another.
Example: A dispatch owner can transfer a request to field operations after scheduling is complete.
A record of responsibility moving from one owner, team, or role to another.
Example: An ownership change can show that a request moved from intake to support.
The decision about who is responsible for a record, task, status change, or follow-up action.
Example: A request can have an assigned owner for daily work and a manager owner for escalation.
A change in who is responsible for a record when work moves between teams or tools.
Example: An ownership handoff can move a lead from intake staff to the sales owner after qualification.
A model that clearly records who owns, created, manages, or is responsible for a workflow record.
Example: A ticket can use an ownership model to track the customer, assigned staff member, and reviewing manager.
A queue organized around who is responsible for each item and which items still need an owner.
Example: An ownership queue can separate My tickets, Team tickets, and Unassigned tickets.
The rule that decides who is allowed or expected to handle the next step for a record.
Example: An ownership rule can require a dispatcher to assign a job before a technician can close it.
A clear change in who is responsible for the next workflow action.
Example: Ownership transfer can assign a lead to sales after intake validation is complete.
A responsive layout decision that determines which dashboard panels deserve the strongest position or visibility first as space becomes tighter.
Example: A dashboard can give panel priority to status, alerts, and next actions before secondary charts on smaller screens.
The top-level business entity that can oversee multiple locations, branches, or units.
Example: A parent organization might need cross-location reporting while each branch handles daily work.
An account structure where one parent organization supervises or reports across multiple child locations, branches, or teams.
Example: A parent-child account can let a franchise owner review several location dashboards from one portal.
A failure where one part of a backend action succeeds while another important part does not finish.
Example: A partial failure can save a request update but fail to send the required notification.
A clear sign that a review step worked as expected.
Example: A pass condition can say the request status changes to reviewed and the confirmation message appears.
A point in a user path where different choices or conditions lead to different next screens or states.
Example: A path branch can send a complete request to review and an incomplete request back to editing.
How fast the interface feels to the user based on feedback, loading behavior, and visible stability.
Example: A page can feel faster when loading states are clear and the main action area stays stable during updates.
A practical limit for how much time, data, or repeated work a backend feature should spend before it needs review.
Example: A performance budget can say that an operations dashboard should not scan years of closed jobs on every page load.
A clear line that explains what a role can view, create, update, approve, or close.
Example: A technician may update job notes while only a manager can approve a refund.
The test that confirms whether the current user is allowed to run the requested backend action.
Example: A permission check can confirm that only supervisors may reopen a completed approval record.
A software rule that allows or blocks a specific action.
Example: A permission rule can allow only managers to approve refunds.
The collection of screens, buttons, routes, and actions where permission decisions are visible or enforced.
Example: A staff dashboard permission surface includes the list page, detail page, edit button, and approval action.
A test that confirms the right user can perform an action and the wrong user cannot.
Example: A permission test can make sure clients cannot open staff-only review tools.
Navigation that stays available while users move between related screens.
Example: A dashboard sidebar can stay visible while the main work area changes.
A layout area that stays available while the user moves between related screens.
Example: A header or sidebar can be a persistent region in a student dashboard.
The person responsible for moving a lead through the next appropriate sales step.
Example: A pipeline owner can be accountable for follow-up timing, proposal status, and next action.
A meaningful step in a lead or sales workflow that shows where the opportunity stands.
Example: Pipeline stages might include inquiry, contacted, qualified, proposal sent, follow-up, won, or lost.
The line between what one plan allows and what another plan does not allow.
Example: A plan boundary should explain why a premium dashboard is locked and what unlocks it.
A move from one membership plan, access level, or subscription option to another.
Example: A plan change should be visible in account history so staff can understand current access.
The practice of checking a user's plan or entitlement before allowing a protected action.
Example: Plan gating can stop a student without the right plan from opening a protected specialty lesson player.
A structured review of portal screens, flows, permissions, content, and states before release.
Example: A portal QA pass can check login, dashboard, ticket, document, and empty-state behavior for each role.
The planned structure of a portal's navigation, overview areas, detail screens, history, and allowed actions.
Example: Portal architecture helps a client find updates, files, messages, statuses, and next steps without staff-only detail.
A clear separation between areas built for different user types.
Example: A client portal boundary keeps customer request updates separate from the internal staff workspace.
A final review that connects portal scope, roles, dashboards, documents, tickets, locations, QA, and rollout evidence.
Example: A portal capstone review can show how client and staff surfaces work together before launch.
The customer-facing information needed to make a portal update understandable and useful.
Example: Portal context can include request title, current status, next step, and expected follow-up.
The menu or path structure that helps portal users find the areas they are allowed to use.
Example: Portal navigation can include Requests, Messages, Files, Billing, and Account depending on the product.
A prioritized list of portal improvements that are useful but not required for the first safe release.
Example: A portal refinement backlog can defer advanced filters while keeping required dashboard and ticket flows ready.
A short plan that explains what portal behavior is ready, what remains watched, and who owns launch follow-up.
Example: A portal release plan can name final QA evidence, support ownership, and post-launch checks.
The clear boundary around what a portal should show, support, and protect in the current build.
Example: A first portal scope may include request status and document access while leaving advanced reporting for later.
A page, card, dashboard, file center, or status area where a portal user reviews or acts on information.
Example: A portal home surface can show open requests, recent updates, documents, and the next action.
A customer-facing status, message, or record change shown through a portal or account surface.
Example: A portal update can tell a client that a request is scheduled without exposing internal staff notes.
The decision about what a person can see inside a portal based on role, account, status, or ownership.
Example: A client may see project status and approved files while staff see internal notes and assignment details.
A selected set of work samples, notes, and evidence that presents a project clearly.
Example: A portfolio package might include a project summary, key screens, QA notes, and a short outcome statement.
A review performed after launch to confirm important user paths still work.
Example: A post-launch check can verify login, signup, dashboards, queues, forms, and protected pages.
A focused list of portal risks, signals, and user paths to monitor after release.
Example: A post-launch watchlist can include upload failures, confusing statuses, overdue tickets, and support questions.
A Django query tool that helps load related records ahead of time when a page needs many related items.
Example: A dashboard can prefetch related notes before showing recent updates for many tickets.
A set of checks run before a handoff to catch obvious readiness problems early.
Example: Preflight verification can check settings, migrations, static files, important pages, and core workflow paths.
The ordered story used to help another person understand the project and its value.
Example: A presentation narrative can move from problem to decisions, evidence, outcome, and next step.
Limited access that lets a user see a small safe part of content or a feature without full tracked access.
Example: Preview access can show the outline of a lesson while keeping the full player gated.
The most important action a user should take on a screen for the current goal.
Example: On a request detail screen, the primary action might be Assign owner or Mark reviewed.
The main navigation that moves a user between major areas of an app.
Example: A portal can use primary navigation for Dashboard, Lessons, Support, and Account.
The main area where the user's current task should stay clear and readable.
Example: In a support screen, the primary workspace might show the selected ticket conversation.
A label, count, or signal that shows which work needs attention first.
Example: A priority indicator might highlight high-priority tickets waiting on staff review.
A clear urgency label that tells people how quickly an item should be handled.
Example: A priority level such as normal, high, or critical should mean something specific to the team.
A visible cue that helps a user decide which item needs attention first.
Example: A priority signal can call out an overdue task, blocked approval, missing file, or urgent customer update.
A plain explanation of the real problem the software project is meant to solve.
Example: A problem statement can say staff lose track of requests because intake, assignment, and status updates live in separate places.
A repeated place where a workflow becomes slow, confusing, risky, or hard to track.
Example: A pain point may be that staff copy the same request details into three different tools.
The practical line between one product responsibility and another inside a growing application.
Example: A support product boundary can separate ticket intake from subscription billing.
The practice of making a Django product more reliable, safer, and easier to support before or after release.
Example: Hardening can include permission checks, clearer errors, safer defaults, and recovery paths.
A concise explanation of what a product does, why it matters, and what evidence shows it is ready.
Example: A capstone presentation can summarize the workflow, risks, tests, and next improvements.
The real live environment or version of a software system that actual users depend on.
Example: A production readiness check asks whether login, pages, settings, and important workflows still work for real users.
A setting used by the real live version of a software system.
Example: A production setting should be reviewed carefully because it can affect real users.
A compact portal area that summarizes where a request stands and what happens next.
Example: A progress panel can show current status, recent update, next step, and expected follow-up.
A compact explanation of what has been completed and what remains.
Example: A progress summary can help a reviewer understand which screens are built and which checks are pending.
The clear story that explains a project's problem, plan, build choices, review, and outcome.
Example: A project narrative can help another person understand why the capstone was built the way it was.
A compact explanation of what was built, who it served, and what problem it addressed.
Example: A project summary can introduce a dashboard build before showing screens or decisions.
A required piece of evidence used to support a generated document or proof record.
Example: Completion time, staff name, work note, and customer approval can be proof fields.
A missing evidence step where the workflow claims something important happened but the expected supporting file or record is absent.
Example: A proof gap appears when the job is marked complete but no required completion image is attached.
Supporting evidence that helps confirm work was completed or reviewed.
Example: A completed repair request can include a photo as proof of work.
The backend path that collects, stores, reviews, and preserves evidence tied to a real request or operational event.
Example: A proof workflow can keep upload review, approval, and storage history attached to the original job record.
A workflow that records evidence showing what was done, when, and for whom.
Example: A proof-of-work flow can attach completion notes, timestamps, and photos to a customer record.
A backend action that can change important data, status, or ownership and therefore needs stronger checks.
Example: Closing a ticket, changing an owner, or issuing a refund can all be protected actions.
A multi-record change guarded by permissions, scope limits, preview, and confirmation.
Example: A protected bulk change should not run until the staff user can see what will be affected.
An intake route that requires the right signed-in user or scope before a request can be submitted.
Example: A protected client intake path can attach the request to the signed-in client's account.
A user journey that only the right account, plan, role, or enrollment should be able to open.
Example: A protected user path can keep clients, students, and staff inside the areas meant for them.
A Django page or action that requires the right signed-in user and access rule before it opens.
Example: A protected view can show a staff dashboard only after the app confirms the user has staff access.
A workflow action that needs extra review because it affects sensitive data or outcomes.
Example: Deleting a record, approving a refund, or exporting a report can be a protected workflow step.
A message intended to be visible to the requester, client, student, or other allowed non-staff user.
Example: A public reply can tell the client what information is needed next.
The user-facing state that tells whether content is draft, preview, ready, live, or unavailable.
Example: A lesson can show preview while the paired article remains draft.
A practical list of review steps used to check whether software behavior matches the expected outcome.
Example: A QA checklist can include form validation, permission checks, dashboard counts, and user path review.
A lead that appears to fit the business, need, timing, or budget well enough for the next sales step.
Example: A qualified lead may be ready for a proposal, estimate, consultation, or deeper follow-up.
The line that explains where database lookup details should live so views do not become crowded with query decisions.
Example: A reporting query boundary can keep filter and ordering rules in a helper instead of repeating them across several views.
The habit of reviewing backend data access so each query stays purposeful, scoped, and explainable.
Example: Query discipline helps a dashboard load only the records it needs instead of pulling every job into memory.
A focused helper that keeps common database lookup, filtering, or ordering rules reusable.
Example: A query helper can return active tickets for a dashboard without copying filter rules into every view.
The practice of making database lookups more focused and efficient without changing the result users need.
Example: Adding select_related for a list that always shows each ticket owner can reduce repeated database lookups.
The limits that decide which records a backend query is allowed or expected to retrieve.
Example: A query scope can limit a report to active requests for one location and one date window.
A dashboard value created by asking a Django QuerySet a focused question about saved records.
Example: A request dashboard can use a QuerySet summary to show how many requests are waiting for review.
The practice of reducing unnecessary clicks, searching, guessing, and duplicate review inside a queue.
Example: Queue efficiency improves when each card shows owner, blocker, status, and next action without opening every record.
An option that narrows queue items by status, owner, priority, date, role, or condition.
Example: A queue filter can show only blocked approvals assigned to the current employee.
The person or team responsible for keeping a queue reviewed, routed, and unblocked.
Example: A dispatch queue owner can review aging requests and assign blocked items to the right next owner.
A list screen that helps staff see work items needing attention.
Example: A service queue view can show new, unassigned, overdue, or in-progress requests.
One unit of delayed backend work waiting for a job runner to process it.
Example: A queued work item may represent one reminder, export, or follow-up check waiting for its turn to run.
A review step that confirms whether a specific launch condition is satisfied.
Example: A readiness check can compare a button label, page title, feature claim, and actual available behavior.
Concrete proof that a product area is ready for review, release, or continued refinement.
Example: Readiness evidence can include passing tests, review notes, screenshots, migration checks, and support plans.
A rule that decides who should receive a notification or reminder.
Example: A recipient rule can send an overdue reminder to the current owner instead of everyone.
A short explanation that summarizes the most believable sequence of backend events after reviewing the history.
Example: A reconstruction note can explain that the approval succeeded first, then the reminder retried against stale ownership data.
The ordered path a record follows from creation through updates, completion, and archival.
Example: A ticket record lifecycle can move from new to assigned to in progress to completed.
The ability to restore or reopen a record after it was archived, hidden, or mistakenly removed.
Example: Record recovery can let a staff member restore an archived request if the customer follows up.
A grouped count or summary made from many related records.
Example: A record rollup can show how many tickets are waiting, assigned, or overdue.
The category of saved item, with fields and behavior that match its job.
Example: A service request and an invoice are different record types because they support different work.
A change to a saved business item after a user action or workflow step.
Example: Changing a ticket from New to In review is a record update.
A saved point in the workflow that helps the team decide what already happened and what should happen next after failure.
Example: A recovery checkpoint can record that the status changed but the follow-up email did not send.
A detail in backend history that points to the safest next review or repair step after a problem is found.
Example: A recovery clue might show the last clean state before a duplicate reminder path started running twice.
The person or team responsible for reviewing and repairing a failed automated workflow.
Example: A recovery owner can review failed document generation before the customer receives a packet.
The planned way a team responds when a problem appears after release.
Example: A recovery path can include pausing a feature, reverting a change, or directing users to a safer flow.
A saved explanation of what failed, what was repaired, who handled it, and what changed afterward.
Example: A recovery record can show that a failed handoff was retried, corrected, and reviewed by operations.
A focused pass that improves clarity, safety, or reliability after the first working version exists.
Example: A refinement pass can simplify a staff workflow, clarify errors, or add a missing regression check.
A test or review that protects behavior that broke before or could easily break again.
Example: A regression check can make sure a completed lesson still unlocks the next specialty lesson.
A clear rule for how Django models should connect without creating confusing or circular responsibility.
Example: A visit can belong to a ticket, but billing approval may belong to an invoice rather than the visit itself.
A short list of checks that must pass before a Django product change is treated as ready to release.
Example: A release checklist can include tests, migrations, static files, configuration, and rollback notes.
The settings and environment choices that shape how a Django product runs when it is prepared for release.
Example: Allowed hosts, debug mode, email settings, static file settings, and database URLs can be release configuration.
A problem found during or after launch that may affect users or staff.
Example: A release issue might be a broken form, missing asset, wrong access rule, or failing dashboard count.
The practical state where the team has enough checks passed to consider a feature ready for launch.
Example: Release readiness can include matching content, clear labels, completed review steps, and no known launch blockers.
A short explanation of whether a workflow is ready, blocked, or needs more review before broader use.
Example: A release readiness note can say that a reporting export is ready after sensitive columns are removed.
A final check that confirms a portal is safe, clear, accessible, and aligned with role and data boundaries before launch.
Example: A release-readiness review can verify that preview data, permissions, and support paths are ready.
A rule that decides when a person should be reminded about unfinished work.
Example: A reminder rule can notify an owner when a request is due tomorrow.
One visible update pass where the interface redraws after data, state, or layout changes.
Example: A long render cycle can make a filter panel feel slow even if the request itself finished quickly.
A signal showing where an account stands in its renewal or continuation path.
Example: Renewal state can help staff see whether an account is renewing, overdue, paused, or nearing expiration.
The rule that explains when a completed or closed record is allowed to move back into active work.
Example: A reopen rule can require a reason, a new owner check, and a fresh status note.
An action that stays harmless or unchanged if the backend tries to run it more than once.
Example: Writing the same reminder sent marker twice can be a repeat-safe action when it does not create duplicate side effects.
The person or system identity responsible for a comment or reply in a thread.
Example: A reply author helps readers know whether an update came from staff, a client, or the system.
The exact set of records, fields, and dates a report or export is supposed to include.
Example: A report scope can limit an export to one franchise location and the current month only.
The backend record of when a report or export ran, what scope it used, and which version of the data it represented.
Example: A report trace helps the team explain why one export differs from a later rerun of the same report.
A screen that organizes records and summaries to answer an operational question.
Example: A report view can show requests completed by team and date range.
A Django surface that summarizes useful product or operations information so people can review patterns and status.
Example: A reporting dashboard can show open tickets, overdue follow-ups, and recent completion trends.
The level of detail a report uses, such as request, customer, team, day, week, or month.
Example: A daily request-count report has a different grain than a per-customer service history report.
The backend path that collects, transforms, and presents operational data for dashboards, exports, or recurring reports.
Example: A reporting pipeline can turn request records into a weekly completion summary for leadership review.
The boundary that defines which records, time period, and filters a report is meant to include.
Example: A weekly support report might include open tickets from the last seven days for one team.
The path from a user's action to the software's handled result and feedback.
Example: Submitting a support form starts a request cycle that ends with confirmation or guidance to fix a field.
The path a service request follows from first intake to final completion or closure.
Example: A request lifecycle might move from new to assigned, in progress, waiting, resolved, and closed.
The saved data shape for a service request or similar operational record.
Example: A request model can store requester, details, priority, status, owner, and submitted time.
The expected fields, names, and formats a caller must send into a backend boundary.
Example: A request shape can require job_id, note_text, and reason fields before a protected update runs.
Information that explains who submitted a request and how the app should treat that request.
Example: Requester context can include whether the request came from a public visitor, signed-in client, or staff member.
A field that must be filled in because the next workflow step depends on it.
Example: A request title can be a required field because staff need it to understand the work.
Information a form must receive before the action can be completed.
Example: An email address may be required so staff can reply to a service request.
A backend link that must exist before a record is considered valid for the next workflow step.
Example: A required relationship can mean a follow-up record must stay attached to the original ticket before closure is allowed.
A file that must be provided because the workflow cannot continue without it.
Example: A reimbursement request may require a receipt upload before review.
A simple group used to sort project needs by purpose, urgency, or phase.
Example: Requirement buckets can separate must-have workflows, later improvements, access rules, and reporting ideas.
A clear description of what the software should do, for whom, and under what conditions.
Example: A requirement statement can say a manager can filter open requests by owner and status before assigning follow-up.
A support status label that explains where a request is in the resolution process.
Example: Resolution states can include new, assigned, waiting on client, in progress, resolved, and closed.
The sequence of intake, assignment, investigation, update, action, and closure steps used to resolve a support request.
Example: A resolution workflow can move a ticket from new to assigned, waiting on client, resolved, and closed.
The fields, names, and meaning a backend boundary returns after it handles a request.
Example: A response shape can return status, message, and updated_at so the caller knows what changed.
A clear line that explains who owns a step and when responsibility changes.
Example: A ticket can move from support owner to billing owner when the problem becomes a payment issue.
A review step that confirms a screen still works and reads well on narrower or wider devices.
Example: A reviewer narrows the browser and checks that cards stack cleanly instead of overlapping.
A planned change in layout behavior when the screen width needs a different arrangement.
Example: A two-column dashboard can shift to one column when the workspace becomes narrow.
A field that only certain users should be able to see or change.
Example: An internal cost note can be a restricted field on a service request.
A state change that only certain roles or verified situations are allowed to trigger.
Example: Moving a request from disputed to approved may be a restricted transition reserved for reviewers.
A short message that tells the user how many matching items are visible.
Example: A search panel can say, 'Showing 4 matching lessons.'
The time marker that starts the countdown for how long a file or proof item should stay in the workflow.
Example: A retention clock may begin at request completion, approval, or a later archive-ready event.
The rule that decides how long a file, proof item, or supporting record should stay available before archival or removal.
Example: A retention rule can keep completion photos for one period while temporary exports expire much sooner.
A clue that an account may need follow-up to keep the subscriber engaged or supported.
Example: Retention signals can include expiring access, repeated support requests, canceled status, or low activity.
A check that keeps a repeated backend job from running the same important action again when the correct result already exists.
Example: A retry guard can stop a second reminder job from creating another identical escalation entry.
Plain instructions that help a user try again after something fails.
Example: After a failed upload, retry guidance can explain what file type to choose next.
The maximum number of times automation should try a failed step before pausing for review.
Example: A retry limit can pause a failed export after three attempts and route it to staff.
A condition that decides when automation should try a failed step again.
Example: A retry rule can wait ten minutes before trying a temporary CRM update failure again.
A workflow designed so a failed or repeated background attempt can be retried without damaging the product record.
Example: A retry-safe invoice sync checks the invoice status before applying a new status change.
A safe way for a person to go back, review, or continue after finishing a step.
Example: A confirmation screen can include a return path back to the dashboard.
A planned pause where a person checks automated work before it continues.
Example: A review checkpoint can hold a high-value quote before a customer message is sent.
The concrete notes, checks, or examples that support a backend review decision.
Example: Review evidence can include the specific transition, query path, or recovery safeguard the reviewer inspected.
A specific issue or improvement note found during a structured review.
Example: A finding might say: the error message is visible, but it does not tell the student what to fix.
A planned point where the work is checked before moving to the next stage.
Example: A review milestone can happen after requirements, after the first build, or before presentation.
The decision recorded after a person reviews paused automated work.
Example: Approve, correct, reject, and escalate can be review outcomes.
A place where records wait for a person to clarify or correct them before automation continues.
Example: A review queue can hold incomplete CRM leads until staff choose the correct region and owner.
A final or near-final step where the user checks collected information before saving the completed workflow.
Example: A review step can show the customer address, service request, and preferred appointment window before final submit.
A count or measure that helps people evaluate automation behavior without hiding the underlying context.
Example: A reviewable metric can show completed runs, skipped records, retry counts, and review-path volume.
A record of changes over time that helps the team understand how the work evolved.
Example: Revision history can show when requirements, QA notes, and launch labels changed.
A planned round of review, adjustment, and recheck.
Example: A revision loop can turn QA notes into fixes before the final presentation.
A planned time after release for reviewing feedback and making small improvements without treating the update as unfinished.
Example: A revision window can let staff review confusing copy or missing fields after the first week of use.
A simple list of backend workflow risks tied to specific triggers, states, or handoff points.
Example: A risk map can show that a reopened ticket may skip reassignment if the state rules are loose.
A condition that decides when automated work is risky enough to require review.
Example: A risk threshold can pause automation when a request exceeds an approved amount.
A limit that explains what a type of user may see or do.
Example: A client role may view approved updates while a staff role can edit internal notes.
A dashboard view shaped around what one approved user type needs to review or act on.
Example: A manager role dashboard can focus on team workload, escalations, and location summaries.
The practice of naming practical groups of users by the work they need to do in the system.
Example: Dispatcher, technician, manager, billing reviewer, and customer can each need different access.
The first useful portal destination for a specific role after login or tenant selection.
Example: A client role entry point may be the timeline while an employee entry point may be assigned queue items.
A clear check that decides whether a user role can open a screen or run an action.
Example: A manager role gate can allow refund approval while blocking the same action for a regular support role.
A simple list of user roles and the portal areas, records, and actions each role needs.
Example: A role map can separate client, employee, manager, and administrator visibility before screens are designed.
A menu designed around the work and permissions of a specific user type.
Example: A manager role menu can emphasize reports, assignments, and escalations.
The group of dashboard paths that are visible and useful for one user role.
Example: A support role route set may include ticket inbox, assigned work, customer lookup, and reply history.
The range of records, actions, or screens a role is supposed to reach inside the workflow.
Example: A technician role scope may allow status updates on assigned jobs but not reassignment of other teams' work.
The practice of keeping user responsibilities distinct across navigation, records, and actions.
Example: Role separation keeps staff tools, client requests, and student progress in the right areas.
Navigation that changes by user role so each person sees the portal areas they can safely use.
Example: Role-based navigation can show clients documents and timelines while employees see queues and internal workspaces.
A demonstration that shows portal behavior from each role without exposing restricted data or internal-only notes.
Example: A role-safe demo can show client, employee, manager, and admin views with safe sample records.
The planned way to undo or safely limit a backend change when continuing would make the workflow less trustworthy.
Example: A rollback path can restore the previous assignment rule if a new dispatch path causes missed jobs.
A prepared fallback path for pausing, limiting, or reversing a change if rollout problems appear.
Example: A rollback plan can explain when to pause the new request queue and how staff continue urgent work.
A planned action that reverses or safely compensates for an automated change that should not stand.
Example: A rollback step can cancel a duplicate reminder task and record why it was removed.
A practical concern that could make a software change confusing, disruptive, unsafe, or hard to adopt.
Example: A rollout risk may be that staff do not know which old spreadsheet should stop being used.
A summary surface that combines approved information from multiple child locations for a parent account.
Example: A rollup view can show open tickets across all locations while still linking back to each branch.
The rule that decides whether a page, link, or destination should appear for a user.
Example: A billing route may be visible to account staff but hidden from service technicians.
The urgency or order assigned to a record before automation chooses the next destination.
Example: A routing priority can place urgent records ahead of standard requests without hiding why.
A clear condition that chooses where work should go based on reviewable workflow details.
Example: A routing rule can send complete urgent service requests to dispatch.
A piece of request information that helps decide where work should go next.
Example: Service category, location, urgency, customer type, and missing details can all be routing signals.
A check that confirms incoming data is usable before automation chooses a route.
Example: Routing validation can require category, location, and urgency before assigning a request.
A table behavior that lets a person choose one or more rows before taking a related action.
Example: A queue table can use row selection so a reviewer can choose several items before assigning them.
A fallback setting that avoids risky behavior when a specific value is missing.
Example: A safe default can keep a feature unavailable until the team intentionally marks it ready.
A calmer backup behavior that protects the record or user when the preferred backend path cannot finish.
Example: A safe fallback can show a pending-review message instead of marking a failed workflow complete.
Sending work to the right queue, owner, or next step only after required context is clean enough to use.
Example: Safe routing can hold an intake record for review when the service category is missing.
A review of whether automation safeguards are pausing, routing, and recording work as intended.
Example: A safeguard audit can compare review checkpoint volume with the issues staff actually found.
Information the app has stored so it can be found, updated, reviewed, or used again later.
Example: A service request becomes a saved record after the app stores the submitted details.
A table column that is intentionally designed to be read quickly because it answers a frequent decision or status question.
Example: A status scan column can help staff find overdue work without reading every cell in the row.
The path a person's eyes are likely to follow while trying to understand a screen quickly.
Example: A clean card title, status line, and action row support a predictable scan pattern.
A layout that helps people quickly compare and find important information.
Example: Aligned columns and clear badges make a ticket list easier to scan.
An automated task that runs at a planned time or repeated interval.
Example: A scheduled job can send daily follow-up reminders for requests waiting on response.
A practical line that separates the current software problem from later improvements.
Example: A scope boundary can keep a first version focused on intake and routing before adding reporting dashboards.
A mistake where a role can see or trigger an action outside the area the workflow meant to allow.
Example: A scope leak can happen when a staff role can reassign another team's tickets from a shared queue.
A short clarification that explains what is included, excluded, or deferred in a requirement.
Example: A scope note can say version one includes manual assignment, while automatic routing waits for later planning.
An action limited to a clear set of records, users, statuses, plans, or permissions.
Example: A scoped action can update only selected overdue requests instead of the entire database.
A limited group of actions that are allowed for a specific user type, role, record state, or workflow area.
Example: A scoped action set can let staff assign a request while preventing clients from changing staff-only fields.
The planned path a person follows from one screen or step to another.
Example: A service request screen flow can move from request form to review to confirmation.
The way app screens are grouped from major areas down to specific details.
Example: A support area can contain a ticket list, ticket detail, reply form, and history view.
A planning view that names the major screens in a software flow and how they connect.
Example: A screen map can connect a dashboard, request detail, assignment form, confirmation screen, and review page.
The surrounding labels, headings, regions, and messages that help screen reader users understand where they are.
Example: A table heading and clear filter labels give context before a user reviews rows.
A meaningful area of a screen with a clear job.
Example: A sidebar, main content area, and action footer are screen regions.
The move from one screen or panel to another inside a workflow.
Example: Opening a support ticket detail page from a ticket list is a screen transition.
A focused area that holds search input, search feedback, and related options.
Example: A ticket list can place its search box, result count, and clear action in one search panel.
The word or phrase a person enters to find matching items.
Example: Typing billing into a search box is a search query for billing-related items.
Navigation inside a specific portal area that helps users move between related subpages or filters.
Example: Secondary navigation can let a manager move between Exceptions, Approvals, and Reassignments.
A situation where sensitive information becomes visible somewhere it should not appear.
Example: Secret exposure can happen if a token or password is pasted into a page, lesson, support note, or error message.
Sensitive information that should be protected and never shown in normal lessons, pages, logs, or public messages.
Example: A secret value can be a password, token, key, or private connection detail.
The visible condition that shows whether a table row or item is currently selected for the next action.
Example: A clear selection state helps the person confirm which rows will be affected by a bulk action.
A token named by its role in the interface instead of by the raw color or number it happens to use.
Example: A token named surface-border is easier to reuse than one named light-gray-2.
A report field that needs extra review before export because it may expose internal, personal, or operationally restricted data.
Example: A sensitive column might include private notes or internal ownership details that should not leave staff-only tools.
The software's answer after it receives and handles a request.
Example: A server response can tell the screen that a ticket was saved or that a required field is missing.
A clear agreement about what one backend service or endpoint expects, returns, and keeps stable for its callers.
Example: A service contract can define the allowed request fields and the response shape for a scheduling endpoint.
The ordered path a request follows from accepted work to finished service and follow-up.
Example: A delivery workflow can move from assigned, scheduled, in progress, waiting on customer, completed, and closed.
A small Django code layer that holds workflow decisions outside the view so the same action can be reused and tested.
Example: A ticket service can assign a ticket, add a status note, and return the result without putting all of that logic inside one view.
The full path a service request follows from intake to closeout.
Example: A service lifecycle can move through New, Assigned, In progress, Waiting, Completed, and Closed.
A focused Django app concept that helps a team receive, track, update, and complete service work.
Example: A service operations mini app can connect intake, assignment, status movement, comments, summaries, and protected paths.
A common sign-in foundation that can support different role-aware experiences after login.
Example: A shared auth layer can identify the user before sending staff, clients, and students to different portals.
The risk created when too many workflows depend on one model for unrelated reasons.
Example: A single Account model used for sales, billing, support, and reporting can become risky if every change touches it.
An extra system change that happens because one action triggered more than the main record update.
Example: Saving a ticket may also send an email notification as a side effect.
A responsive behavior where a sidebar becomes narrower, hidden, or moved behind a menu.
Example: A portal can collapse its sidebar on small screens so the lesson stays readable.
A final review item that confirms the agreed conditions have been checked before handoff.
Example: A sign-off check can confirm the core workflow, access boundary, and visible feedback all match the plan.
A form flow where one page collects the needed values and saves the record in one clear action.
Example: A basic profile update can often work as a single-step form.
A reusable layout approach where specific content areas are reserved for roles such as heading, metadata, actions, or support text.
Example: A slot pattern helps a builder know where optional badge, summary, and action content should appear inside a component.
A clue that a backend query or loading pattern may be taking too long or doing too much work.
Example: A slow query signal can be a report that times out whenever the date range grows.
The time range the reporting pipeline uses when it captures a picture of backend data for a summary or export.
Example: A snapshot window can define which requests count in today's operations report.
A safer removal approach that hides or deactivates a record without permanently erasing it immediately.
Example: A soft-deleted task can be hidden from the active list while still being recoverable.
The clear boundary around what a software build or improvement is expected to include.
Example: A request intake scope might include collecting contact details and service category, but not billing automation yet.
An option that changes the order of a list without changing the list items.
Example: A sort option can show newest requests first.
The system that is trusted as the main home for a specific kind of data.
Example: A CRM may be the source of record for lead stage while an operations dashboard owns service status.
An account meant for internal team members who operate, review, or manage the software.
Example: A staff account may open assignment queues and review protected service records.
An internal action that changes product data and should be limited to the right staff role or scope.
Example: Changing ticket priority, assigning a reviewer, or closing an escalation can be staff actions.
A staff-facing screen that helps qualified team members review, assign, update, and monitor service work.
Example: A staff operations view can show a queue, filters, assigned owner, status, notes, and next actions.
An internal feature intended for allowed staff users rather than customers, students, or public visitors.
Example: A staff tool can help review queues, assign owners, or clean up stale records.
Internal product screens or actions designed for trusted staff workflows rather than public customers.
Example: A staff tool can help managers review escalated tickets without exposing that review screen to customers.
The internal software area where team members manage records, queues, and protected actions.
Example: A staff workspace may include service tickets, assignment queues, and review dashboards.
The movement of a lead from one pipeline stage to another after real progress happens.
Example: A stage transition should happen because a call was completed, a quote was sent, or a decision was made.
A review environment used to check software before treating it as ready for public use.
Example: A staging environment can help a team review a portal workflow before people depend on it.
A specific need from someone affected by the system, such as a customer, staff member, manager, or owner.
Example: A dispatcher may need faster routing while a customer needs clear status updates.
A clear message that tells affected people what changed, why it matters, and what they should do next.
Example: A stakeholder update can tell staff that billing review now uses a queue instead of email forwarding.
An exported file that no longer matches the current record truth because the reporting pipeline used outdated data.
Example: A stale export can mislead a team when assignments changed after the file was generated.
A screen area that still shows outdated information after the user changes something.
Example: A result count can become stale if it does not update after a search.
A lead that has not moved forward after enough time or after an expected next action.
Example: A stalled lead should be visible so the team can follow up, close it, or update its stage.
Helpful context that stays understandable as a user moves between connected screens.
Example: A selected filter can stay visible when the user returns from a detail page to the list.
A meaningful change in a record or workflow status that can affect what should happen next.
Example: Changing a request from scheduled to completed is a state change that may trigger a follow-up.
A simple list or sketch of the interface states, triggers, and visible responses that belong to one workflow.
Example: A state map can show default list, filtered list, empty results, and saved confirmation states for the same screen.
A difference between what the screen should show and what the current interface state actually shows.
Example: A filter says Active but the list still shows inactive items.
A single move from one record state to another based on a clear rule or trigger.
Example: Moving a job from scheduled to dispatched is one state transition.
A test that confirms a record moves from one allowed status to another in the expected way.
Example: A state transition test can check that a request changes from new to assigned only after assignment.
A version of a component that changes because of a known interface state like loading, warning, success, or disabled.
Example: A loading state variant should still preserve the same general structure so the interface stays predictable.
The practice of treating record states and transitions as clear rules instead of loose labels.
Example: State-machine discipline keeps a ticket from jumping to completed before the required review step happens.
Confidence that CSS, JavaScript, images, and collected static files will load correctly outside local development.
Example: Static asset readiness protects the live app from unstyled pages and missing scripts.
A short visual label that communicates the state of something.
Example: A lesson badge might say Not started, In progress, or Completed.
A summary that groups records by their current status.
Example: A status breakdown can show New, Assigned, Waiting, and Resolved ticket counts.
A history item that records a record's move from one status to another.
Example: A status change entry can say the ticket moved from New to Assigned.
The practice of explaining progress clearly enough that users understand what happened and what comes next.
Example: A status update can explain that a document was reviewed and the next step is waiting on approval.
A model that records important status changes over time instead of only storing the current state.
Example: A request status history can show who moved a job from waiting to scheduled and when that happened.
A short, consistent name that tells users where work currently stands.
Example: Clear status labels such as Waiting on approval or Scheduled are easier to understand than internal abbreviations.
The planned set of states a record can move through over time.
Example: A ticket status lifecycle might move from New to Assigned to Waiting to Resolved.
A short update that tells the user what changed after an action or validation check.
Example: After saving a profile, a status message can say Changes saved.
A small set of clear status names that explain where work currently stands.
Example: A status model can separate new, assigned, waiting, in progress, ready for review, and closed work.
A quick summary of how many records sit in important workflow states right now.
Example: A status snapshot can show New, Assigned, Waiting, Overdue, and Closed counts.
A compact explanation of where work stands without requiring the user to open every detail page.
Example: A status summary can show three active requests, one blocked item, and the next required action.
A summary count grouped or filtered by workflow status.
Example: A dashboard can show status totals for New, Assigned, Waiting, and Completed requests.
A permitted movement from one status to another in a workflow.
Example: A request may move from assigned to scheduled, but not directly from new to closed without review.
A short communication that explains current progress, recent movement, and what needs attention next.
Example: A status update can say a workflow is ready for review, blocked by missing copy, or waiting on QA feedback.
The saved information that explains where a user is inside a multi-step workflow and what has already been collected.
Example: A wizard step state can remember that the customer finished contact details but has not confirmed scheduling yet.
Validation that checks the current workflow step before the user moves forward.
Example: Step validation can require a service category before the wizard shows scheduling options.
The line between where a file is stored, who may reach it, and how the backend should reference it safely.
Example: A storage boundary helps the workflow avoid exposing internal file locations directly in a public-facing view.
A log entry that records useful fields consistently so product events are easier to search and understand.
Example: A structured log for a failed report export might include user id, report id, status, and error category.
An account meant for a learner whose access is shaped by lessons, progress, and enrollment.
Example: A student account can open eligible lessons while staff-only tools stay hidden.
A learner-facing area focused on lessons, progress, assignments, and support.
Example: A student portal can show the next lesson, saved progress, homework, and practice history.
Feedback that tells the user their submitted form was received and what happens next.
Example: A confirmation message can tell the client that the request was saved and is waiting for review.
The organized account record used to understand a subscriber's plan, status, access, and history.
Example: A subscriber record can show plan name, renewal state, access state, support notes, and recent changes.
A product rule that uses a user's subscription or plan state to decide access.
Example: A subscription rule can block a canceled account from opening premium actions.
A clear sign that the project or workflow has solved the right problem.
Example: A success condition might say staff can assign new requests in under a minute with no duplicate entry.
The clear ending that tells a person their action worked.
Example: A confirmation message is a success state after a form is sent.
A small dashboard block that presents one important number or state with a clear label.
Example: A summary card might show Open requests, Unassigned work, or Waiting on client.
A small number or measure that helps people understand workflow state quickly.
Example: A dashboard can show a summary metric for open requests this week.
A transfer of ownership, context, and next action from one support role or team to another.
Example: A support handoff should keep the ticket summary, latest action, owner, and due date visible to the next team.
The state of having help materials, owners, triage paths, and known issue handling ready before launch.
Example: Support readiness can include a help note, escalation contact, and list of expected first-week questions.
A portal screen or list that shows support requests with the fields each role needs to understand status and next action.
Example: A support ticket view can show clients the request status while staff see assignment and resolution details.
A readable path of support updates that shows what was said, who acted, and what changed.
Example: A support trail can reduce repeated explanations when a ticket changes owners.
How easy it is for staff to diagnose, explain, and resolve product problems without guessing.
Example: A supportable workflow shows relevant status, timestamps, user context, and next steps.
A file that adds context or evidence for a record without always being the main record.
Example: A signed approval form can be a supporting document for a customer request.
A check across the places where users can see related content or feature promises.
Example: A surface review can compare the app screen, website page, login message, and support note for the same feature.
The line where one software system's responsibilities end and another system or workflow begins.
Example: A system boundary can separate website intake from CRM ownership and billing updates.
A final review project that combines process scope, workflow design, access, reporting, rollout, and change-management decisions.
Example: A systems capstone can review an intake-to-closeout workflow before a team treats the plan as build-ready.
One vertical category of information in a table.
Example: A status column can show whether each request is waiting, active, or complete.
The amount of information a table shows in each row and column before scanning starts to feel crowded or tiring.
Example: A denser table can still work if the key columns, spacing, and actions stay easy to scan.
One horizontal item in a table.
Example: A service request row can show one request and its current status.
A compact record summary that helps staff understand one work item before opening the full detail view.
Example: A task card can show request title, client, priority, owner, blocker, and due date.
The boundary where one part of a product records enough information for another process to finish later.
Example: A checkout flow can hand off receipt email work to a background task with the order id and recipient.
The recorded status that helps staff or code understand whether background work is pending, running, done, or failed.
Example: A report export can move through pending, processing, ready, and failed task states.
A screen or panel that helps an employee understand and complete a specific set of work.
Example: A task view might show assignment, status, due date, next action, and recent update.
The account, organization, workspace, or client group that a portal record belongs to.
Example: Tenant context helps the system decide which users can safely see a project, file, request, or report.
A controlled interface that lets an authorized user move between accounts or organizations they are allowed to access.
Example: A tenant switcher can help an agency manager review multiple client portals without mixing their records.
A state that should end the normal lifecycle unless a specific reopen rule is used.
Example: Completed can be a terminal state until a verified reopen path is triggered.
The amount of important behavior protected by focused checks.
Example: Good test coverage protects key workflows without trying to test every harmless detail.
The records, users, permissions, and starting states a test creates before checking behavior.
Example: A staff view test may set up a staff user, a customer record, and one pending approval.
The job a token plays in a visual system, such as background, border, text, accent, or warning.
Example: A theme role helps a builder decide where a token belongs before styling a new component.
A new message, note, reply, or status-related entry added to a ticket thread.
Example: A thread update can record a client reply, a staff comment, or a status explanation.
A focused place where incoming support or service requests wait to be reviewed, routed, assigned, or answered.
Example: A ticket inbox can show new, urgent, overdue, and assigned support requests in one organized view.
A clear signal that helps staff decide which support request needs attention first.
Example: Ticket priority can mark a blocked launch issue as urgent while a general question stays normal.
The ordered discussion and update history attached to a ticket or support-style record.
Example: A ticket thread can show staff notes, client replies, status notes, and follow-up updates.
One dated item in a timeline that explains a status change, message, file, or required action.
Example: A timeline event can record that a proposal was sent on Tuesday and approval is due Friday.
A saved update that includes when it happened.
Example: A timestamped update can show that a note was added at 2:15 PM.
A small organized set of reusable values, often for spacing, size, or typography, that keeps interfaces consistent.
Example: A spacing token scale can keep cards, panels, and buttons from using random padding values.
A final lesson or build that combines the important ideas from a track into one stronger learning task.
Example: A track capstone helps students connect separate lessons into one realistic software plan.
A short plan for teaching users what changed, how to do the work, and where to get help.
Example: A training plan can include a walkthrough, quick reference, support contact, and first-week check-in.
A condition that must pass before a record is allowed to change from one state to another.
Example: A transition guard can require a technician assignment before dispatch is marked complete.
A short plan that explains when a team moves from the old workflow to the updated software behavior.
Example: A transition plan can name the switch date, old-tool cutoff, training note, and support owner.
A moment where the user moves from one screen, state, or decision to another.
Example: Clicking Assign on a queue row can be a transition point from review to assignment.
A review list where incoming work waits until staff decide priority, owner, or next action.
Example: A triage queue can show new requests that need category review before assignment.
A clear decision rule that helps staff decide priority, category, owner, or next step for incoming work.
Example: A triage rule can send urgent billing issues to a manager while routine questions stay in support.
A review screen that helps staff sort incoming items by urgency, category, ownership, and next action.
Example: A triage view can help a lead decide which tickets need assignment before the team starts answering.
An account in a temporary evaluation period before a full membership decision.
Example: A trial account may need onboarding help, feature limits, renewal prompts, or conversion follow-up.
The specific rule that must be true before an automated workflow begins.
Example: A trigger condition may require a settled invoice and a confirmed customer email before sending onboarding steps.
A safety check that prevents an automation from running when required context is missing or unsafe.
Example: A trigger guard can stop a reminder if the appointment time or contact method is blank.
A visible cue that helps users understand portal status, ownership, safety, or next action.
Example: A trust signal can show when data was last updated, who owns a ticket, or whether a file was accepted.
A compact interface piece that groups a small amount of related information and action.
Example: A lesson card can show a title, minutes, progress state, and button.
A clear expectation for how a reusable interface piece should behave, what content it needs, and what can safely change.
Example: A card contract might say every variation needs a title, status, and primary action area even if the layout shifts slightly.
A larger grouped area that holds related actions, information, or status.
Example: A support panel might show the ticket summary, next step, and owner.
The current condition of an interface at a specific moment.
Example: A filter panel can be open, closed, empty, searching, or showing matching items.
A queue of work items that need an owner before progress can continue.
Example: An unassigned queue helps staff catch requests that may otherwise sit untouched.
The number of open records that do not currently have an owner.
Example: An unassigned total can reveal work that may be stuck before anyone reviews it.
Work that has been created but does not yet have a responsible person, role, or team.
Example: Unassigned work should appear clearly so it does not sit unnoticed.
The amount of visible work the interface has to do when one interaction changes the screen.
Example: A table that redraws every row after one small filter change may have a higher update cost than needed.
The safe route a user follows to change a record and understand what changed.
Example: Changing a request status from New to Assigned should follow a clear update path.
A review step that confirms a file belongs to the right record, meets the expected type, and reached the workflow safely.
Example: An upload checkpoint can verify that a proof photo belongs to the current request before it is marked complete.
Clear instructions that explain what file is needed, why it is needed, and what happens after upload.
Example: Upload guidance can ask for a signed estimate and explain that staff will review it before scheduling.
The current condition of an uploaded file, such as pending review, accepted, rejected, missing, or replaced.
Example: An upload state can show that a signed form was received but still needs staff review.
The current state of a file upload or attachment review.
Example: An upload status can be missing, uploaded, needs review, approved, or rejected.
The useful result a specific user type is trying to reach with the software.
Example: A support user goal might be to find the next ticket, reply clearly, and mark the request ready for review.
The larger story of what a person is trying to do and how the software helps them get there.
Example: A student journey may start on a lesson page and end with saved progress.
The route a person follows through screens to complete a specific goal.
Example: A staff user path might move from dashboard to queue row to detail screen to saved follow-up.
A named responsibility or access type that helps the app decide how a user should be treated.
Example: Staff, client, and student roles can send users to different dashboards after login.
The set of screens, records, and actions a user type should be able to reach.
Example: A student user scope may include lessons and progress while excluding staff review tools.
A supporting panel for secondary actions, details, filters, or helper information.
Example: A lesson screen can use a utility panel for resources, progress, or notes.
A rule that must stay true every time a record is created or changed so the workflow remains trustworthy.
Example: A validation invariant can require every completed request to keep a saved completion note and owner history.
A focused review that checks whether the work meets the expected behavior and acceptance criteria.
Example: A validation pass can confirm that forms, dashboards, permissions, and empty states behave as planned.
A repeatable way an interface checks input and explains what needs to be fixed before the person can continue.
Example: A validation pattern can show inline guidance beside a field and a short summary near the top of the form.
A rule that checks whether entered information is usable before the workflow continues.
Example: A validation rule can require a service request to include a contact email before it is submitted.
A number that looks impressive but does not help staff make a useful decision.
Example: Total records ever created may be less useful than active overdue requests this week.
A focused round of checks used to confirm important behavior before or after launch.
Example: A verification pass can check a login path, main workflow, article link, and dashboard summary.
One specific action a reviewer takes to confirm expected behavior.
Example: A verification step can ask the reviewer to submit the form, reopen the record, and confirm the saved value.
The first useful version of a software project, limited to the work needed for a reliable starting point.
Example: Version one might include intake, assignment, status, and basic review before adding deeper automation later.
A backend contract that names which version of the boundary behavior callers are using so changes can be introduced safely.
Example: A versioned contract can let one dashboard use the old response shape while another moves to the improved response.
The part of a Django view that should stay focused on request handling, response choice, and user-facing flow.
Example: A view can read form input, call a service, and choose the next template without owning every workflow rule itself.
A test that checks whether a Django view returns the right status, template, redirect, or visible response.
Example: A view test can confirm that an anonymous user is redirected away from a staff-only page.
A rule that separates customer-safe information from internal, restricted, or role-specific information.
Example: A visibility boundary can keep staff-only escalation notes off the client dashboard.
A clear visual cue that shows which link, button, input, or element currently has keyboard focus.
Example: A focused sidebar link can show an outline so the user knows where they are.
The order of visual importance created by headings, spacing, contrast, grouping, and placement.
Example: A strong heading, quieter helper text, and a clear action button make the next step easier to see.
A status that shows work is paused because a person, approval, detail, or outside event is needed.
Example: Waiting on customer is clearer than leaving a service request marked in progress when no staff action can happen yet.
A calm message that tells the user something may need attention before they continue.
Example: A portal form can warn that unsaved changes will be lost if the user leaves.
A rough screen sketch that shows structure, content areas, and important actions before detailed building begins.
Example: A wireframe can show a queue header, filter row, record list, and primary action without final colors or polish.
A saved task, request, ticket, or record that someone needs to act on.
Example: A submitted service request becomes a work item when staff need to review or assign it.
A list of work items awaiting review or action in a defined order.
Example: A work queue can sort urgent approvals above routine follow-up so staff know where to start.
The process of sending a request, task, or record to the right person, queue, or next workflow step.
Example: A routing step can assign a new repair request to dispatch after intake confirms the service category.
A path that changes based on a condition, decision, or record state.
Example: A request with missing proof of work may branch back to review instead of closing.
A meaningful moment where the app confirms a record is ready to move to the next workflow step.
Example: A workflow checkpoint might confirm assignment before an item moves from new to in progress.
The feeling that connected screens still belong to the same task and keep the user oriented.
Example: A dashboard and detail page share labels and status text so the task still feels connected.
A focused function or service method that handles one reusable product workflow step.
Example: A workflow helper can reopen a request while keeping the ownership and status rules in one place.
A simple view of the steps, people, records, and decisions involved in a business process.
Example: A workflow map can show intake, review, assignment, scheduled work, customer update, and closeout.
A short note that explains context, decisions, or follow-up inside a workflow.
Example: A workflow note can say customer asked to be called after 3 PM.
A reviewed exception path that lets the app handle a workflow differently when the normal path does not fit.
Example: A staff manager may need a workflow override to reopen a closed request with a reason.
The ordered route a user follows through screens to complete a task.
Example: A support workflow path can move from inbox to ticket detail to reply and completion.
A clear sign that a work item has moved forward through its expected path.
Example: Changing a request from Assigned to In progress can show workflow progress when work has started.
A final review that confirms an automated workflow has clear triggers, safe actions, review paths, and support records.
Example: A workflow readiness check can catch missing rollback steps before automation goes live.
One screen in a connected task path that helps a person move from one step to the next.
Example: A ticket list, ticket detail page, and edit form can each be a workflow screen.
A named step in the path a record follows from start to finish.
Example: Review, approval, fulfillment, and follow-up can each be workflow stages.
The current named condition of a request, task, or record in a workflow.
Example: New, scheduled, waiting, completed, and canceled can be workflow states.
A test that checks a product action across more than one model, service, view, or state change.
Example: A workflow test can confirm that approving a request changes status, records the reviewer, and creates a note.
The event or condition that starts an automated step.
Example: A newly settled invoice can be a trigger for sending onboarding instructions.
A filter that lets staff narrow a queue by owner, status, urgency, date, or other work context.
Example: A workload filter can help a manager review one employee's active tasks without scanning the whole queue.
A compact view of how work is distributed across people, queues, roles, or statuses.
Example: A workload summary can help a manager see whether one staff member has too much active work.
The main part of an app screen where the current task or content appears.
Example: In a portal, the workspace area might show the selected lesson, ticket, or settings form.
A repeatable set of steps used to solve a problem.
Example: A sandwich recipe is an algorithm because you can follow it step by step.
The software you use to open and view websites.
Example: Chrome, Edge, and Firefox are all browsers.
Written instructions that tell a computer what to do.
Example: A line of HTML that makes a heading is code.
A language used to style how HTML content looks.
Example: CSS can make a title blue or add space around a card.
A program developers use to write and organize code files.
Example: VS Code is a popular code editor.
The ending of a filename that tells you what type of file it is.
Example: The .html part of index.html is the file extension.
A container used to organize files on your computer.
Example: You might store website images inside an images folder.
A named set of instructions that can be reused when you need it.
Example: A function can show a welcome message every time a button is clicked.
A markup language used to structure content on a webpage.
Example: HTML tells a page which text is a heading and which text is a paragraph.
A programming language that adds behavior and interactivity to webpages.
Example: JavaScript can show a message after you click a button.
A reserved word in a programming language with a special meaning.
Example: In Python, if and def are keywords.
Text that labels pieces of content so software knows what they are.
Example: HTML tags are a form of markup.
A beginner-friendly programming language used for websites, automation, and data work.
Example: Django apps are often built with Python.
A computer or service that sends website files and data to a browser.
Example: When you visit a website, a server sends the page back to your browser.
The writing rules a language expects you to follow.
Example: Missing a closing quote breaks the syntax of many languages.
A text-based tool used to run commands on a computer.
Example: You can start a Django server from the terminal.
The address used to reach a page on the web.
Example: https://example.com/about is a URL.
A named place where code stores a value so it can be used later.
Example: A variable can store a student's name before showing it on the page.
A note in code that helps humans read it but does not run as part of the program.
Example: A comment can explain why a variable exists without changing the result.
Leading spaces that show structure in some languages, especially Python.
Example: Python uses indentation to show which lines belong together.
The result a program shows after it runs.
Example: If you print a name, the displayed name is the output.
A common Python function used to display output.
Example: print("Hello") shows Hello as output.
A piece of text in code, usually written inside quotes.
Example: "Hello" is a string because it is text wrapped in quotes.
A machine that follows instructions very exactly.
Example: A computer can open a website or run an app when the code tells it how.
A label in HTML that tells the browser what a piece of content is.
Example: The h1 tag tells the browser that text is a main heading.
A full HTML piece made from a tag and the content it wraps.
Example: An opening p tag, a sentence, and a closing p tag make a paragraph element.
A clear step that tells a computer what to do.
Example: A line of code can be one instruction in a larger program.
Extra information added inside an HTML tag.
Example: The href attribute inside an a tag tells a link where to go.
A set of instructions a computer can run to do a job.
Example: A calculator app runs as a program.
Clickable text or an image that takes you to another location.
Example: A navigation link that opens the About page is a hyperlink.
A program or group of programs people use on a computer or device.
Example: A website dashboard or phone app is software.
A single saved item on a computer, such as a page, image, or script.
Example: index.html is a file in a web project.
HTML that uses meaningful tags so people and browsers can understand the job of each section.
Example: Using header, main, and footer is more semantic than using generic div tags for everything.
The full name of a file, including the ending that shows its type.
Example: style.css is a filename.
A page area where users type information and send it somewhere.
Example: A name field and submit button together are part of a form.
A value that is only true or false.
Example: is_logged_in could be true when a student is signed in.
A group of files and folders that work together to build something.
Example: A small website can be one beginner project.
Something that happens in the browser that code can react to.
Example: A button click is an event.
A common file extension for an HTML page file.
Example: index.html is often the main page file in a simple website.
The browser's structured view of the page that JavaScript can read and change.
Example: JavaScript can use the DOM to change a heading after a click.
A common file extension for a CSS file that holds styles.
Example: styles.css can control colors, spacing, and fonts.
A browser tool where developers can see messages and test small bits of code.
Example: console.log can send a quick message to the console while you debug.
A common file extension for a JavaScript file.
Example: script.js can hold page behavior and interactions.
A group of related web pages people can visit in a browser.
Example: An academy site can have a home page, lesson pages, and article pages.
A common file extension for a Python file.
Example: app.py is a common name for a Python file.
One screen of content a browser can display.
Example: A lesson screen inside the Academy is one page.
The first HTML tag that starts a piece of content.
Example: The <p> part at the start of a paragraph is an opening tag.
One page inside a website that a browser can display.
Example: A contact page is one web page on a larger site.
The ending HTML tag that shows where a piece of content stops.
Example: The </p> part at the end of a paragraph is a closing tag.
The organized shape of a page and the parts it contains.
Example: Headings and paragraphs help give a page structure.
The information on a page, such as text, images, and links.
Example: A heading, a paragraph, and a picture are all page content.
A short name that tells people what a page or section is about.
Example: A main heading can act like the title for the page content.
A title or section label that helps organize a page.
Example: The main title at the top of a page is often a heading.
A grouped part of a page that covers one topic.
Example: A lesson page can have one section about headings and another about paragraphs.
A block of regular text that explains an idea on a page.
Example: A short explanation under a heading is often a paragraph.
Easy for a person to look at and understand.
Example: A page with a clear heading and short paragraph feels more readable.
The place a link is meant to take someone.
Example: A contact page can be the destination of a navigation link.
Clickable content that takes you to another page or location.
Example: A menu item that opens the About page is a link.
A picture shown on a web page.
Example: A logo or photo on a page is an image.
The file or location an image or other media comes from.
Example: A logo.png file can be the source for an image on a page.
The way something looks on a page.
Example: Color and spacing are part of a page's style.
Related to what people can see on a page.
Example: A photo is visual content because people look at it on the page.
The visible look of a page or page element.
Example: CSS can change the appearance of a button.
Content such as images or other visual items shown on a page.
Example: A page banner image is one simple kind of media.
A visual property that changes how text or backgrounds look.
Example: A heading can appear blue because of its color setting.
A group of related items shown together on a page.
Example: A short set of features can appear as a list on a web page.
The visual style used for text letters on a page.
Example: CSS can change the font of a paragraph.
A list used when the order of the items matters.
Example: Steps for making tea can appear in an ordered list.
The amount of room around or between page parts.
Example: More spacing can make a page feel easier to read.
A list used when the group matters more than the order.
Example: A list of favorite snacks can be an unordered list.
One entry inside a list or group.
Example: One bullet point in a feature list is one item.
The way page parts are arranged on the screen.
Example: A two-column page has a different layout from a one-column page.
The overall visual plan for how a page should look and feel.
Example: Color, spacing, and layout all affect a page's design.
Several related pieces kept together so they make sense as one set.
Example: A heading and its matching list can be grouped together on a page.
To arrange things clearly so they are easier to read or use.
Example: Lists help organize repeated items on a page.
A styling instruction that tells CSS how something should look.
Example: A CSS rule can make all headings a certain color.
What a page or app does when someone uses it.
Example: Showing a message after a click is page behavior.
Describing something by what it means or what job it has.
Example: A semantic tag tells you what part of the page it represents.
The top or introductory area of a page or section.
Example: A site title and short intro can sit inside a header.
A moment when a person does something and the page responds.
Example: Typing in a box and seeing feedback is an interaction.
Pressing a mouse button or trackpad on something on the page.
Example: Clicking a button can open a menu.
The closing area at the bottom of a page or section.
Example: Contact details at the bottom of a page can live in a footer.
Information a person enters or action they give to a program.
Example: Typing your name into a field is input.
The part of a page that helps people move to other pages or sections.
Example: A menu with Home and Contact links is navigation.
A standalone piece of content on a page.
Example: A blog post preview can be one article on a page.
What the page or program does after something happens.
Example: A thank-you message after a button click is a response.
The primary content area of a page.
Example: The central lesson content often belongs in the main area.
A piece of code that helps a page do something.
Example: A small JavaScript file can act like a script for page behavior.
The idea or purpose something is meant to show.
Example: A semantic tag adds meaning because it tells you the job of that page part.
A language people use to write instructions for computers.
Example: Python is a programming language.
Using software to handle repeated tasks automatically.
Example: A script that renames files for you is a small automation.
One place in a form where a person can type or choose something.
Example: A name box is one field in a contact form.
To send the form information after filling it in.
Example: A submit button sends the form after the user is ready.
Something you use to help complete a task.
Example: A code editor is one tool developers use every day.
Easy to approach when you are still new.
Example: A beginner-friendly lesson explains one idea at a time.
Details or data that a page can show or collect.
Example: A form can collect information like a name or email address.
A tool developers use to write and update code files.
Example: VS Code is one example of a code editor.
A note or piece of text someone can send through a form.
Example: A contact form can include a message field for a question.
A word used to identify a person or thing.
Example: Many forms ask for a person's name first.
Written words or characters shown on a screen or saved in a file.
Example: Code is a special kind of text a developer can edit.
An address people use to send and receive messages online.
Example: A sign-up form may ask for an email address.
To store your latest file changes so they are not lost.
Example: When you save a file, your edits stay there the next time you open it.
An option a user can select in a form or on a page.
Example: A yes-or-no option in a form is one choice.
To change or update something that is already written.
Example: Fixing one line of code is an edit.
One row of text or code inside a file.
Example: A short program might start with one line of code.
A person using the website, app, or tool.
Example: The user fills in the form and clicks submit.
Text that tells the user what a field is for.
Example: Name is a label for a name field.
Color-coding in an editor that helps different parts of code stand out.
Example: Keywords and strings may appear in different colors because of syntax highlighting.
A page element the user can press to trigger an action.
Example: A Send button can submit a form.
The working area where your files and tools are organized together.
Example: A project folder opened in an editor can become your workspace.
One part of a form where information is entered or chosen.
Example: A name box is one form field.
Something written or done the wrong way by accident.
Example: Typing the wrong file name is a small mistake.
The action that sends form information.
Example: Clicking Send starts the submit action.
A change that corrects a problem.
Example: Adding the missing quote can fix the bug.
An input used for short typed text.
Example: A first name box is usually a text input.
An input used for an email address.
Example: A sign-up form often includes one email input.
To check whether something works the way you expect.
Example: After a small code change, you can test it again to see the result.
Hidden text a user types to protect an account.
Example: A password field hides the letters as the user types.
To try again after something did not work the first time.
Example: After a small fix, you can retry the step calmly.
Looking for a mistake and fixing it calmly.
Example: If a paragraph does not look right, debugging means checking the tags one step at a time.
Something that is not working correctly and needs attention.
Example: A blank result when you expected a message is a problem to investigate.
A mistake in code that causes a problem.
Example: A missing closing tag can be a small HTML bug.
What happens after code runs or after you test a change.
Example: If the page now shows the right message, that is the result of your fix.
A problem or wrong part that needs attention.
Example: Typing a tag name wrong can create an HTML error.
A very small piece of code used as an example.
Example: print("Hi") is a tiny code snippet.
The link destination written inside an HTML link.
Example: A link uses href to point to another page.
Something you notice repeating in code or examples.
Example: Seeing words followed by values can become a familiar pattern.
The source value that tells an image where to load from.
Example: An image uses src to point to the picture file.
A character in code, such as =, ( ), or quotes.
Example: The quotes around "Hi" are symbols you will learn over time.
A file that stores CSS rules for a page or website.
Example: styles.css is a stylesheet that can control page colors and spacing.
A small sample used to help explain an idea.
Example: A one-line snippet can be an example of how code looks.
The part of a CSS rule that chooses which page element to style.
Example: p is a selector when you want to style every paragraph.
One property and value pair inside a CSS rule.
Example: color: navy; is one declaration.
To look at code carefully so you can understand what it is doing.
Example: You can read one line of code at a time instead of rushing.
The part of a CSS declaration that names what you want to change.
Example: color is the property in color: navy;.
One small action in a larger task or process.
Example: Reading one line before changing it is one step.
A repeatable way of moving through a task from start to finish.
Example: Read, change, and check can be part of a beginner coding process.
The part of a CSS declaration that gives the chosen setting.
Example: navy is the value in color: navy;.
The area behind text or content inside a page element.
Example: A soft gray card background can help separate one section from another.
A specific piece of work you want to complete.
Example: Fixing one line of code can be a small task.
A visible line around an element.
Example: A border can outline a card or button.
A small update or adjustment you make while working.
Example: Changing one word in a file is a small change.
To look at the result and see whether something worked.
Example: After a small change, you can check the result.
Space outside an element.
Example: Margin can create room between two cards.
Space inside an element, between the content and the border.
Example: Padding keeps text from touching the edges of a box.
To do a useful step again so understanding grows over time.
Example: You may repeat the same small practice more than once while learning.
A beginner way to think about content, padding, border, and margin together.
Example: A card can be understood as content in the middle with padding, a border, and margin outside.
Forward movement, even when it happens in small amounts.
Example: Finishing one lesson step is real progress.
A reusable label you place on HTML so CSS can style it again and again.
Example: A class named card can style many cards the same way.
Repeating a skill in small ways so it becomes more familiar.
Example: Short coding practice helps ideas stick.
To go back over something so you can understand it better.
Example: Reviewing one lesson step can make the next step easier.
How wide an element is allowed to be.
Example: A card might use a width that keeps it readable on the page.
To create something step by step.
Example: You can build a tiny page by adding one simple part at a time.
How tall an element is allowed to be.
Example: An image area may use a fixed height to keep cards even.
A CSS setting that affects how an element behaves in the layout.
Example: display can help an element act more like a block or a flex container.
To reach the end of a task after doing the needed steps.
Example: A beginner can finish a tiny project without making it huge.
Fully done, with the main steps finished.
Example: Saving the last small step can make a lesson feel complete.
A CSS layout system that helps line items up in rows or columns.
Example: Flexbox can place two cards side by side with controlled spacing.
Design that adapts to different screen sizes instead of staying fixed.
Example: A desktop row of cards may stack into one column on a phone.
Making a page usable by more people, including people using keyboards, screen readers, or different devices.
Example: Adding clear labels and useful alt text improves accessibility.
A protected staff area used to manage content, records, or settings.
Example: A Django admin page can let staff update lesson records safely.
How content edges line up so a layout feels organized and easier to scan.
Example: Cards in the same row should usually share a clean top alignment.
Short text that describes an image for accessibility and fallback display.
Example: A product photo might use alt text like 'blue notebook on a desk'.
A focused part of a project that handles one area of behavior or data.
Example: A support app might hold forms, views, and models for support requests.
To add a new item to the end of a list.
Example: Calling tasks.append('Email client') adds a new task after the existing ones.
A value passed into a function when it is called.
Example: In greet('Mia'), 'Mia' is the argument.
An ordered collection of values; in beginner JavaScript lessons this usually means a list-like group.
Example: ['HTML', 'CSS', 'JavaScript'] is an array of topic names.
A file used by a page, such as an image, stylesheet, script, PDF, or font.
Example: A logo image and style.css are both site assets.
A careful review that checks whether something is complete, accurate, or safe.
Example: A content audit can find lessons missing vocabulary links.
A shared template that holds layout pieces many pages reuse.
Example: A base template might include the header and footer for every Django page.
A named template area that child templates can fill or replace.
Example: A page might fill the title block and content block.
A Django model field that stores true or false values.
Example: is_published can be a BooleanField on a content record.
One possible path a program can take after a condition is checked.
Example: An if branch can run when a student chooses 'yes'.
A planned pause point used while debugging to inspect what is happening.
Example: A breakpoint can help you check a variable before the next line runs.
A clear prompt that tells the visitor what to do next.
Example: A button labeled 'Start the lesson' is a call to action.
A final practice task that combines skills from earlier lessons.
Example: A capstone might combine forms, layout, and beginner validation.
Text near an image, table, or figure that explains what it shows.
Example: A chart caption can explain what the numbers mean.
A small grouped layout block for related content.
Example: A lesson card can show the title, summary, and start link.
The CSS decision process that chooses which style wins when rules overlap.
Example: A more specific selector can win in the cascade.
A Django model field for short text values.
Example: A title field is often a CharField.
A blueprint for creating objects that share data and behavior.
Example: A beginner class can describe a simple support ticket object.
Form input after Django has checked and normalized it.
Example: A valid email field appears in cleaned_data after form validation.
User input after trimming or normalizing it for safer use.
Example: Turning ' YES ' into 'yes' creates cleaned input.
A group of related values, such as a list, dictionary, or array.
Example: A list of lesson names is a collection.
A vertical set of cells or layout items.
Example: A table column might hold every student's status.
A small script that helps with a task by reading simple text input and printing a result.
Example: A helper script can format a request summary.
A check that compares values and returns true or false.
Example: age >= 18 is a comparison.
A reusable piece of interface or page structure.
Example: A pricing card can be treated as a component.
A true-or-false check used to decide what code should run.
Example: if score >= 80 uses a condition.
Code that chooses between paths based on a condition.
Example: An if/else statement is a conditional.
A layout wrapper that groups content and controls width or spacing.
Example: A page container keeps text from stretching too wide.
The process of creating, editing, reviewing, and publishing content records.
Example: Staff use content management to update lesson pages.
Data sent from a view to a template so the page can render dynamic content.
Example: A lesson title can be passed into template context.
The visible difference between colors, especially text and background.
Example: Dark text on a light background usually has stronger contrast.
Information stored or processed by software.
Example: A student's lesson progress is data.
A structured place where an app stores records.
Example: A database can store lessons, users, and progress.
A Django model field that stores a date and time.
Example: submitted_at can use a DateTimeField.
To find and fix a problem in code or behavior.
Example: Reading an error message is part of debugging.
A collection that stores values under named keys.
Example: {'name': 'Ava'} is a dictionary.
A Python web framework for building organized web applications.
Example: Django can connect URLs, views, templates, and database models.
Page content that is filled from data instead of written directly into the HTML each time.
Example: A dashboard greeting can show the signed-in student's name dynamically.
A Python keyword that means 'else if' and checks another condition.
Example: elif status == 'pending' checks a second path.
A fallback branch that runs when earlier conditions do not match.
Example: else can show a default message.
A Django form or model field that expects an email-shaped value.
Example: A contact form can use EmailField for the visitor's email address.
A specific thing software lets a user do.
Example: Saving draft code is a Practice Lab feature.
An HTML element that groups related form inputs.
Example: A fieldset can group contact preference options.
An HTML element for self-contained media such as an image with a caption.
Example: A product screenshot with a caption can be placed in a figure.
A control or condition that narrows a list to matching items.
Example: A track filter can show only Python lessons.
The order of steps a user or program follows.
Example: A signup flow may move from form to confirmation to dashboard.
A loop that repeats once for each item in a collection.
Example: A for loop can print each topic in a list.
A set of tools and patterns that helps organize common software work.
Example: Django is a framework for Python web apps.
The moment code asks a function to run.
Example: format_name('mia') is a function call.
Space between layout items.
Example: CSS gap can add space between grid cards.
An HTTP request method commonly used to ask for a page or read data.
Example: Opening a lesson page usually sends a GET request.
A CSS layout system for arranging content in rows and columns.
Example: A card grid can show three lesson cards per row.
A small script that performs a focused useful task.
Example: A helper script can clean input and print a summary.
The main top section of a page that introduces the page and next action.
Example: A landing page hero usually has a heading and button.
A unique identifier used to point to one specific element or record.
Example: An HTML id can link to a section on the same page.
A Python keyword that starts a conditional check.
Example: if score > 0 checks whether score is positive.
A number that marks an item's position in an ordered collection.
Example: In a list, index 0 points to the first item.
A template pattern where one file reuses or extends another shared file.
Example: A page template can inherit a base layout.
The part of software a person uses to interact with it.
Example: A form is an interface for sending information.
Software used by a team inside a business, not usually by the public.
Example: A staff dashboard is an internal tool.
One pass through a repeated loop.
Example: Each item printed by a loop happens during an iteration.
A text format for structured data using objects, arrays, keys, and values.
Example: An API response can return JSON.
The name used to look up a value in a dictionary or structured object.
Example: In {'lesson': 'HTML'}, lesson is the key.
Information stored with clear names so its meaning is easier to understand.
Example: A dictionary stores labeled data with keys.
Text that labels a fieldset group in a form.
Example: A legend can say 'Contact preference' above radio buttons.
The number of a line in a file, often used to locate code or an error.
Example: An error message may point to line number 12.
Code that repeats a task.
Example: A loop can show each item in a list.
Changing text to lowercase so comparisons are more predictable.
Example: Turning 'YES' into 'yes' helps a conditional match.
When one value, pattern, or condition fits another.
Example: A validation rule passes when the output matches the expected text.
A CSS rule that applies styles for certain screen sizes or device conditions.
Example: A media query can stack cards on small screens.
A small practice build that combines a few lessons without becoming overwhelming.
Example: A contact-card page can be a mini project.
A Django class that describes a type of database record.
Example: A Lesson model can store a title, summary, and order.
A numeric value used for counting, math, ordering, or comparisons.
Example: 3 and 12.5 are numbers.
A value that groups related data and behavior.
Example: A student profile object can hold account-related information.
Values kept in a sequence where position matters.
Example: A list keeps lesson titles as ordered values.
A named input a function is designed to receive.
Example: name is a parameter in def greet(name).
A route or file location that tells software where something is.
Example: /lessons/ is a URL path.
Temporary or example text that shows where real content or input belongs.
Example: An input placeholder might say 'Email address'.
An HTTP request method commonly used to submit data.
Example: Submitting a form usually sends a POST request.
The order code runs and the path it takes through choices or loops.
Example: A conditional changes program flow.
The agreed boundary for what a software project is trying to solve and what it will include first.
Example: A project scope can say that version one includes intake, dashboard review, and status updates, but not advanced reporting yet.
Text that asks a user or student to respond.
Example: A lab prompt tells the student what to build or check.
A request for matching data from a database or list.
Example: A query can find lessons in one track.
A sequence of numbers often used for repeated loops.
Example: range(3) can help a loop run three times.
User input before it is cleaned or checked.
Example: ' urgent ' is raw input before stripping spaces.
One saved item in a database or system.
Example: One student progress row is a record.
A path written from the current file or location instead of from the site root.
Example: images/logo.png can be a relative path.
To turn data and templates into visible page output.
Example: Django can render a template into an HTML page.
Repeating an action, usually with a loop.
Example: Printing every item in a list uses repetition.
A message sent to a server asking for a page or action.
Example: A browser sends a request when you open a URL.
Able to adapt layout and content to different screen sizes.
Example: A responsive page works on phones and laptops.
To send a value back from a function.
Example: return total gives the caller the calculated total.
Code written so it can be used in more than one place.
Example: A formatting function is reusable code.
A URL pattern that connects a request to the right app behavior.
Example: /contact/ can be a route.
A horizontal set of cells or layout items.
Example: A table row can show one student.
A feature that helps find matching records or content.
Example: A search box can find lessons by title.
Work that happens on the web server before the browser receives a response.
Example: Django views run server-side.
Configuration values that tell an app how to behave.
Example: A Django settings file can define installed apps.
A short program that handles one focused task.
Example: A small script can clean a name and print a greeting.
A CSS scoring idea that helps decide which selector wins.
Example: .card h2 is more specific than h2.
Team members who manage, review, support, or operate the platform.
Example: Staff can review lesson readiness.
The current saved condition or value of something.
Example: A lesson can have a completed state.
A place or system where data or files are kept for later use.
Example: A database provides storage for records.
A string method that removes extra space from the start and end of text.
Example: ' hi '.strip() becomes 'hi'.
Information organized with clear fields, names, or relationships.
Example: A dictionary is a simple structured data format.
Information a student or user sends for review or processing.
Example: A homework answer is a submission.
A short result a script prints or shows after processing data.
Example: A helper script can print a summary output for a request.
A structure for displaying data in rows and columns.
Example: A progress report can use a table.
A file that defines page structure and placeholders for dynamic data.
Example: A Django template can show a lesson title from context.
Small steps that make text easier to compare or display.
Example: Stripping spaces and lowercasing input are text cleanup steps.
A form control for longer text input.
Example: A feedback form can use a textarea for comments.
A Django model field for longer text values.
Example: A lesson body can be stored in a TextField.
A connected visual style for a page or site.
Example: A theme can define colors, spacing, and typography.
A small typing mistake that can change meaning or break code.
Example: Writing pritn instead of print is a typo.
The choice and use of text styles such as size, weight, line height, and spacing.
Example: Good typography makes lesson text easier to read.
Text that asks a user to enter information.
Example: input('Name: ') shows a user prompt.
Checking whether input or output meets expected rules.
Example: A form can validate that email is not blank.
Django code that handles a request and returns a response.
Example: A lesson detail view loads a lesson and renders a template.
A toolkit that helps build web applications with common patterns already organized.
Example: Django is a Python web framework.
Spaces, tabs, or line breaks in text or code.
Example: Extra whitespace around input can be stripped.
A repeatable set of steps for getting work done.
Example: Reviewing a draft before publishing is a workflow.