Issue fields
Every column visible on the Implementation Tracker's Issues tab, what it stores, and whether you can edit it.
Editable fields
These are filled in either through the + New Issue form when you create the issue, or by clicking the cell on the list to edit in place.
| Field | What it stores | Notes |
|---|---|---|
| Title | Short summary of the issue | Required. Keep it specific. |
| Description | Longer explanation | Free-text. What you did, what you expected, what happened. |
| Status | Where the issue is in its life cycle | Open, In progress, Blocked, Done, Won't do. Defaults to Open on a new issue. |
| Priority | How urgently the issue needs attention | Low, Medium, High, Critical. Defaults to Medium. |
| Customer visible | Whether the issue is visible to the customer side | Checked by default. Uncheck for issues that should be visible only to FullClarity. |
| Assignee email | Email address of the person handling the issue | No validation — store whatever email best identifies the person. |
| Assignee kind | FullClarity or Customer | Used to colour-code who currently holds the issue. |
| Linked NetSuite URL | URL of a related NetSuite record | Paste the full browser URL of an invoice, project, estimate, or other record. Optional. |
| Due date | Optional deadline | Use only when there's a hard date — for example, an upcoming go-live. |
Read-only fields
Filled in by the system. You'll see them on the list but can't edit them.
| Field | What it stores | Notes |
|---|---|---|
| # (Issue number) | Sequential number, unique within the engagement | Auto-assigned on create. Issue #1 is the first issue logged on this engagement, #2 is the second, and so on. |
| Created by | Email and display name of the person who logged the issue | Recorded from the active NetSuite session. |
| Created on | Timestamp when the issue was logged | UTC. Displayed in your local timezone in the tracker. |
| Last updated by | Most recent editor's email and display name | |
| Last updated on | Most recent edit timestamp | |
| Linked UAT test | The UAT test scenario this issue was logged from | Only set on issues created from a Fail result on the UAT tab. |
Status — what each value means
| Status | Meaning |
|---|---|
| Open | Newly created, not yet picked up. |
| In progress | Someone is actively working on this. |
| Blocked | Work has stopped, waiting on something else. |
| Done | The issue has been resolved. |
| Won't do | The issue has been discussed and a decision made not to action it. |
Move issues between statuses by clicking the cell and choosing a new value. There's no enforced workflow — any user with access can move an issue to any status. By convention:
- Open → In progress when work starts.
- In progress → Done when the fix is verified.
- In progress → Blocked if something stalls progress.
- Blocked → In progress when the blocker clears.
- Any → Won't do by mutual agreement, with a description note explaining why.
Priority — when to use which
| Priority | When to use |
|---|---|
| Low | Cosmetic or nice-to-have. Won't block go-live; the implementation can ship without it. |
| Medium | Should be resolved before go-live but isn't blocking other work. Most issues land here. |
| High | Must be resolved before go-live. |
| Critical | Blocking other work right now. Stop and address. |
Priorities are set by whoever logs the issue; FullClarity may adjust if a higher-than-warranted priority would crowd out other work. Triage conversations happen in the Description field rather than by silently bumping the priority down.
Customer visibility
Most issues are visible to both sides — this is the point of the tracker. The Customer visible flag exists to support the occasional case where:
- FullClarity wants to track an internal action item against the engagement (for example, "schedule a working session with the customer's accountant") that isn't a customer-facing issue.
- A discussion is happening between FullClarity team members that isn't appropriate to surface to the customer.
Customer-logged issues should almost always stay visible. There's rarely a reason for the customer to hide an issue from FullClarity.
Editing in place vs the form
The + New Issue form is mandatory only for creating a new issue with a title. Once the issue exists, all the editable fields above can be changed directly on the row by clicking the cell. There's no separate "Edit issue" view.
The form is still useful when you want to fill in several fields at once and don't want to chase them across the row.
Related
- Log an issue — creating and updating issues.
- UAT result statuses — the related status set on the UAT tab.