Find the right answer before work gets messy.

What is Track used for?

Track is a project command center for structured delivery work. It helps you keep projects, tasks, proof, comments, requests, and delivery decisions in one organized workspace instead of scattering them across chats, folders, and memory.

Where should I start after logging in?

Start from the workspace or Project Hub. Open an existing project if one has already been created, or create the project first. After that, add boards for major work areas, lists for lanes, cards for real deliverables, and checklist items for execution steps.

Why does my workspace look empty?

An empty workspace usually means no project has been created yet, you have not been added to a project, or your current view is filtered too narrowly. Open the all-projects view first, then confirm that you are using the correct account and project.

What should I create first?

Create the project first. Then create a board, then a list, then cards. This order keeps the work clean because every task belongs to the right project area from the beginning.

What should I do if I am invited to an existing project?

Open the project first and read the board names, active lists, urgent cards, and recent comments before changing anything. This helps you understand the current operating picture before you add updates or proof.

How do I avoid making a messy project on day one?

Do not create many random cards with unclear titles. Start with clear boards, simple lists, and cards that represent real work packages. Put small steps inside checklists and put explanations inside comments.

What is the difference between the homepage and the workspace?

The homepage explains Track and gives entry points. The workspace is where real project work happens. Once you are logged in, most daily actions should happen from the workspace or project pages, not from the homepage.

What is a project?

A project is the main control room for a complete body of work. It can represent a product, client job, system module, UAT cycle, internal build, launch, or delivery stream.

What is a board?

A board separates a project into major areas such as Phase 1, Finance Module, Mobile Fixes, UAT, Launch, or Support. Use boards when the project has several large work streams that should not be mixed together.

What is a list?

A list is a lane inside a board. Common examples are To Do, Doing, Review, Blocked, Done, or Future Work. Lists help everyone see where work currently sits.

What is a card?

A card is a meaningful work package, issue, decision, deliverable, feature, bug, or review item. A card should be important enough to have status, ownership, proof, comments, or dates.

What is a checklist group?

A checklist group organizes steps inside a card. For example, one card can have groups for Build, Test, Evidence, Review, and Future Improvements so the card remains easy to scan.

What is a checklist item?

A checklist item is a specific step that can be completed, tested, or reviewed. It should be small enough that a user can clearly say whether it is done or not done.

When should I use a card instead of a checklist item?

Use a card when the work needs its own owner, status, due date, comments, proof, or review. Use checklist items for smaller steps inside that card. Example: “Build invoice flow” is a card; “Add validation” and “Test parent notice” are checklist items.

Can one project contain multiple phases or waves?

Yes. Use boards to separate phases, waves, departments, modules, or delivery areas. This keeps one project history intact without forcing every detail into one long flat list.

How do I know what to work on next?

Open the project and look for cards by priority, due date, delivery pressure, blocked state, or review state. Start with items that are active, urgent, assigned to you, or blocking other users.

How should I update progress?

Update the exact card or checklist item that changed. Mark work as done only when it is actually complete. Add a comment when context is needed and attach evidence when proof is required.

What should I do when work is blocked?

Do not hide blockers in memory or private chat. Keep the blocked card visible, explain the blocker in a comment, attach proof where available, and make the next required action clear.

Why should notes, rules, references, and future work be separated from execution items?

Execution items affect real completion. Notes, rules, references, and future ideas are useful, but they should not make progress look higher than it really is. Separation keeps delivery reporting honest.

How often should I update a project?

Update the project whenever meaningful work changes: a step is completed, a blocker appears, evidence is added, a review is returned, or a decision is made. The goal is to keep the project truthful, not to create noise.

What makes a good card title?

A good title tells the reader what the work is without needing to open the card. Use action and object together, such as “Fix mobile project grid click” or “Add FAQ section to homepage”.

How do I show something is ready for review?

Move the card or checklist item to the correct review state, add a short comment explaining what changed, and attach proof if the reviewer needs to verify the work quickly.

Where should I attach screenshots or files?

Attach proof to the exact card or checklist item it supports. If a screenshot proves one test passed, attach it to that test item. If it proves the whole feature is complete, attach it to the card.

When should I use a comment instead of evidence?

Use comments for explanation, decisions, blockers, and discussion. Use evidence for screenshots, files, proof links, exported records, or documents that verify the work.

How should I record UAT or testing results?

Use the related card, list the test steps clearly, mark only passed items as complete, and attach screenshots or files to the matching item. Failed tests should remain visible with the reason and next action.

What kind of evidence should I attach?

Attach evidence that helps someone verify the work without asking many follow-up questions. Useful proof includes screenshots, before-and-after images, exported files, error messages, test results, and approval records.

How do I avoid losing important decisions?

Record the decision on the related card, explain why it was made, and attach any proof or reference. Avoid leaving final decisions only in private chats because they become difficult to audit later.

How should I prepare work for handover?

Make sure the card title is clear, the checklist shows real completion, comments explain key decisions, evidence is attached in the right place, and unfinished work is clearly separated from completed work.

Should every card have evidence?

Not every card needs a file, but important delivery, testing, approval, import, export, or production-fix work should have enough proof for another person to understand and verify it later.

What does overdue mean?

Overdue means the expected date or due date has passed while the work is not complete. It does not always mean failure, but it means the item needs attention, explanation, or replanning.

What should I do when an item is at risk?

Update the card before it becomes a surprise. Add a comment explaining the risk, update the next action, adjust ownership if needed, and attach proof if the risk is caused by an error or dependency.

Why does progress not always show 100% when many items are done?

Progress depends on the real execution state of the work. Some items may still be open, blocked, in review, or separated as notes and future work. This keeps completion honest instead of artificially inflated.

How should I use expected delivery dates?

Use expected delivery dates for serious work that has a target. Keep them realistic and update them when scope changes. Dates should help the team plan, not punish users for reporting reality.

What is the best way to manage urgent work?

Put urgent work in a visible lane, use clear titles, assign ownership, add a due date where appropriate, and keep comments current. Urgent work should not be hidden inside vague checklist text.

How do review states help delivery?

Review states prevent unfinished work from being treated as done. They show that execution may be complete, but someone still needs to inspect, approve, return, or publish the result.

What does export do?

Export creates a structured file of project data so work can be backed up, reviewed, moved, or restored later. It is useful before major changes, before imports, and before handover.

What should I do before importing data?

Export the current project first, confirm the import file belongs to the correct project or board, and read any preview or warning before continuing. Never import blindly when you are unsure what the file contains.

What does no delete-by-absence mean?

It means Track should not delete existing records only because they are missing from an import file. This protects existing work when an import file is partial, old, or created for one section only.

What is merge mode?

Merge mode updates matching existing records while preserving the project structure. Use it when the import file belongs to the same work and you want to continue or refresh that work safely.

What is create-as-new mode?

Create-as-new mode imports the content as a separate new structure. Use it when you want a copy, comparison, recovery version, or separate imported project area instead of changing the existing one.

What should I do if I imported the wrong file?

Stop making additional changes, identify what was imported, check the latest export or backup, and record the issue clearly. If create-as-new was used, the mistake is usually easier to isolate than a blind merge.

Why was my import rejected?

An import may be rejected when the file format is invalid, the data does not match the expected structure, required fields are missing, or the file appears unsafe for the selected action.

Who can see a project?

Project visibility depends on membership and role access. If a user cannot see a project, confirm they were added to the correct project and that they are using the correct account.

What is a project member?

A project member is a user connected to a project for visibility, contribution, review, or ownership. Membership helps keep project access intentional instead of open to everyone by default.

How should ownership be used?

Ownership should show who is responsible for moving the work forward. A card can involve many people, but one clear owner prevents confusion when decisions, proof, or review are needed.

What are requests used for?

Requests are used when one person needs action, review, information, approval, or contribution from another person. They help keep collaboration visible instead of buried in private messages.

Can contributors change everything?

Contributors should only change what their access allows. If something is unavailable, it may be protected by role, ownership, project state, or required context.

How do I keep team handover clean?

Use clear card titles, accurate statuses, comments for decisions, evidence for proof, and visible blockers. A new teammate should understand the work without needing a long verbal explanation.

Why is a button disabled?

A disabled button usually means a required field is missing, the user does not have permission, the item is not in the right state, or the page needs the correct project, board, list, or card context first.

What should I do if a dropdown does not open?

Refresh the page, confirm you are logged in, and try again. If it still fails, record the page name, the field name, the action you clicked, and a screenshot so the issue can be fixed quickly.

What should I do if a triangle or tree item does not expand?

Confirm that the item has child records to show, then refresh the page. If the problem remains, capture the exact project, board, or list area where the expand action failed.

What should I do if a project link does not open?

Check whether the project exists, whether you are a member, and whether the click works after refresh. If the link still fails, report the exact project name and where the link was clicked.

What should I do if upload fails?

Check the file size, file type, internet connection, and whether you are attaching the file to the correct card or item. Try again once, then report the error with the file name and page.

What should I do if the page looks broken on mobile?

Refresh the page and confirm browser zoom is normal. If the issue remains, capture a screenshot showing the full problem area and include the device or screen width if possible.

Why do I still see old data after refresh?

Old data can appear when the browser cache, filters, or selected project context has not updated. Try a hard refresh, clear the current filter, and confirm you are viewing the correct project.

How do I use Track safely during UAT?

Create clear test cards, list acceptance steps, mark only verified items as done, attach proof, and leave failed tests visible. Do not hide failed tests because they are the evidence needed for correction.

How should I record production fixes?

Use a clear card for the issue, explain the fault, record the fix, attach before-and-after proof, and keep review or approval visible. Production fixes should be easy to audit later.

Can Track replace all team communication?

Track should not replace every conversation. It should preserve the decisions, proof, status, and next actions that must survive beyond the conversation. Quick discussion can happen elsewhere, but final truth should be recorded in Track.

What is the safest way to run a handover?

Export the project, review open cards, confirm evidence is attached, separate future work from completed work, and make sure every important card has a clear status and owner.

How do I keep Track from becoming noisy?

Use fewer, stronger cards. Avoid duplicate titles, vague notes, and unnecessary comments. Put details where they belong: execution in checklists, discussion in comments, and proof in evidence.

What should I do before a major project cleanup?

Export first, review the current structure, agree on what will be archived or moved, and avoid deleting or merging records unless the team understands the impact.