Permissions

Who can open the Project Tracker, who can edit what inside it, and how visibility works between the customer side and the FullClarity side.

Today's model in one sentence

The tracker is engagement-scoped, not user-scoped — once a NetSuite user can open the tracker menu entry, they can see and edit everything in the workbook that the engagement exposes to the customer side.

That's a deliberate choice for the implementation period: every person involved in setting up the SuiteApp benefits from seeing every issue and every UAT result, and small implementation teams don't need a per-user permissions layer to function.

Who can open the tracker

Anyone with access to the FullClarity menu in your NetSuite account. By default, the tracker is published with All Roles audience, so any role with menu access can launch it.

If you need to restrict access to specific roles:

  1. Open Customization → Scripting → Scripts.
  2. Find the FCTC Tracker Launcher Suitelet.
  3. Open its deployment record.
  4. Set the Audience tab to the specific roles you want to expose it to.

NetSuite administrators can always see all SuiteApp menu entries regardless of audience configuration.

Author input needed

A standard set of recommended NetSuite roles for tracker users (project managers, accountants, administrators) has not been formally codified yet. For now, work with your FullClarity consultant to identify which existing roles in your account should have tracker access.

What everyone with access can do

Once a user is inside the workbook, they can:

  • See every issue on the Issues tab (with the exception of issues FullClarity has marked as not customer-visible — see Visibility below).
  • Create new issues, edit any field on any existing issue, regardless of who created it.
  • See every UAT scenario on the UAT tab.
  • Record results in the active cycle, including marking Pass, Fail, Blocked, or N/A.
  • Start a new UAT cycle (via the Start new cycle action-bar button).
  • Sign off the active cycle (via the Sign off cycle action-bar button).
  • Post notes on any issue, with attachments. Delete their own notes.

There's no role split between editor and reader inside the workbook. Anyone with menu access has full edit rights.

Visibility

The tracker exposes two visibility controls. Both are FullClarity-side concerns — they don't appear in the customer-side workbook — but they affect what customer-side users can see.

Issue-level: customer visible

Every issue has a Customer visible flag, controlled from the FullClarity side. It governs whether the whole issue (and its note thread) shows up in the customer-side workbook.

  • Customer visible = on (default for customer-logged issues) — the issue is visible on both sides. Almost every customer-logged issue stays here.
  • Customer visible = off — the issue is visible only to FullClarity. Used to track internal action items against the engagement (for example, a working session that needs to be scheduled) without surfacing them to the customer.

Note-level: internal only

When a FullClarity consultant posts a note on a visible-to-customer issue, they can mark the individual note as Internal only. The flag affects only that one note, not the whole issue:

  • Internal only = off (default) — the note is visible to both sides.
  • Internal only = on — only FullClarity-side users see the note. The customer-side workbook doesn't show it and doesn't count it in the issue's note badge.

Customer-side users don't see the Internal only toggle on their composer, and any note they post is always visible to both sides. The toggle is a one-way valve for FullClarity to add private context (for example, an internal triage note) without splitting the issue into two.

Notes posted by customers

Customer-side users can't hide their notes from FullClarity. Anything a customer posts on a visible-to-customer issue is visible to both sides — which is the intent of the tracker as a shared workspace.

Audit trail

Every write to the tracker records who did it:

  • Issues — created_by, last_updated_by (email and display name) are stamped automatically from the NetSuite user calling the action.
  • Notes — every note records the author's email and display name, captured at post time. Deletes are soft (the note is hidden but not purged) and record who pressed Delete.
  • UAT results — tester is stamped with the user who recorded the result.
  • UAT cycle sign-off — signed_off_by is stamped with the user who clicked the button.

These fields are not editable in the workbook — they're for audit, not assignment. To say who is responsible for an issue, use the Assignee picker, which is editable.

What's hidden from customers entirely

The tracker is engagement-scoped. From inside one customer's NetSuite account, the tracker can only see data for the engagement that account is bound to. There's no way to browse other engagements, other customers, or any FullClarity-side admin data.

FullClarity staff use a separate web app (FullClarity Connect) to see across all engagements they're working on. The tracker has no awareness that any of that exists.

Future direction

Two things on the longer-term roadmap that aren't yet built:

  • Per-user roles inside an engagement — a future version may distinguish between editor and reader roles inside the workbook, particularly for larger engagements where some participants only need to observe.
  • Approval workflow on UAT sign-off — currently anyone with access can sign off a cycle. A future option may restrict sign-off to a nominated role.

Neither is on the current roadmap — flag the need to your FullClarity consultant if either matters for your engagement.

Last Updated: