Tessera’s security model is built on three principles: use NetSuite’s existing authentication exclusively, enforce access control through NetSuite’s native permission system, and make the authoritative metric value consistent for every viewer while scoping transaction detail to what each user is already permitted to see.
Tessera has no authentication of its own. There is no Tessera login, no API key, no OAuth flow, and no additional credential to manage. Every Tessera surface — portlets, Suitelets, drill-down views, the Metric Wizard, the Registry catalog, the Admin console — is accessed through an active NetSuite session.
A user who can log into NetSuite can interact with Tessera surfaces their role permits. A user who cannot log into NetSuite cannot interact with Tessera at all.
Tessera creates four custom NetSuite roles via SDF. There is no dedicated Tessera Viewer role. Any NetSuite user is an implicit viewer of Standard metric content without needing a Tessera role assigned.
| Role | SDF Script ID | Description |
|---|---|---|
| Tessera Administrator | customrole_tessera_administrator |
Full system access. Installs and configures Tessera, manages the CRL fleet, creates and edits all Portlet Configs, accesses the Admin console, manages health monitoring. |
| Tessera Controller | customrole_tessera_controller |
Creates and approves metrics in the Finance & Accounting domain. Designated Domain Owner for Finance & Accounting approval domains. Creates and edits Portlet Configs. |
| Tessera Domain Owner | customrole_tessera_domain_owner |
Approves metrics in their assigned approval domain(s). May be any department head — not restricted to Finance. Creates and edits Portlet Configs for their domain’s metrics. Sees all metrics across all domains. |
| Tessera Analyst | customrole_tessera_analyst |
Creates draft metrics and components. Forks baseline components. Cannot approve. Views all metrics and drill-down detail. Cannot create Portlet Configs. |
| (implicit) Any NetSuite User | (any existing role) | Views Standard portlets, drills down, exports CSV. No Tessera role assignment required. Restricted portlets show a fallback message. |
The Controller is not the universal metric authority. A VP of Sales designated as Domain Owner for a Sales approval domain governs their own metric definitions without involving Finance & Accounting. Coexisting definitions of the same conceptual metric — one for Finance, one for Sales — are both valid, both governed, and both visible in the Registry catalog. The Metric Resolution Policy (v2) formalizes which definition surfaces where when multiple definitions exist for the same concept.
Domain ownership controls approval rights, not visibility. All Tessera roles see all metric definitions across all domains in the Registry catalog. Transparency is a feature.
| Capability | Administrator | Controller | Domain Owner | Analyst | Any NS User |
|---|---|---|---|---|---|
| View Standard portlets | ✓ | ✓ | ✓ | ✓ | ✓ |
| Drill down on any portlet | ✓ | ✓ | ✓ | ✓ | ✓ |
| Export drill-down to CSV | ✓ | ✓ | ✓ | ✓ | ✓ |
| View Restricted portlets | ✓ | ✓ | ✓ | ✓ | — |
| View Registry catalog | ✓ | ✓ | ✓ | ✓ | — |
| Create draft metric | ✓ | ✓ | ✓ | ✓ | — |
| Fork baseline component | ✓ | ✓ | ✓ | ✓ | — |
| Approve metric (own domain) | ✓ | ✓ | ✓ | — | — |
| Create / edit Portlet Config | ✓ | ✓ | ✓ | — | — |
| Deactivate baseline component | ✓ | ✓ (F&A) | ✓ (own domain) | — | — |
| Manage Approval Domains | ✓ | — | — | — | — |
| Access Admin console | ✓ | — | — | — | — |
| Manage CRL fleet | ✓ | — | — | — | — |
| Manage license | ✓ | — | — | — | — |
The Tessera portlet script deploys to all NetSuite roles (<allRoles>T</allRoles> in SDF). Any user can add a Tessera portlet widget to their personal dashboard. The meaningful access control is not on the portlet deployment — it is on the Portlet Config record (R10).
The portlet script’s first action at render time is to look up the Portlet Config for this portlet instance. Three outcomes:
| Portlet Config state | Render behavior |
|---|---|
| No Portlet Config exists | “No metric configured — contact your Tessera administrator.” |
| Standard Portlet Config | Full metric display: value, chart tabs, drill-down, CSV export. Visible to any NS user. |
| Restricted Portlet Config | Full display for Tessera-role users. “Access restricted” fallback for users without a Tessera role. |
Only Tessera Administrator, Controller, and Domain Owner can create and edit Portlet Config records. This is the gate that controls what metrics appear on whose dashboards.
NetSuite portlet scripts execute as the current logged-in user, not as an administrator. This is load-bearing for the security model.
Metric Result records (R6) have View permission granted to all roles — this allows any user’s portlet session to read the pre-computed metric value. The value itself is always the same authoritative number regardless of who is viewing: it was computed by the CRL, version-linked, and timestamped.
Drill-down queries also execute as the current user. NetSuite’s native record-level permissions naturally scope what each user sees in the transaction detail. A warehouse manager and a CFO viewing the same DSO metric see the same number — but the warehouse manager’s drill-down shows only the transactions their role can access. This is correct behavior. The metric value is authoritative and shared; the underlying detail is role-scoped by the platform.
Each Metric Definition carries a Sensitivity field with two values:
Sensitivity is set by the Controller or Domain Owner at metric creation time and can be changed (with a logged minor change) at any time.
The CRL Map/Reduce fleet executes metric computations. These scripts run under the Tessera Administrator’s execution context — they have sufficient permissions to query the GL data required for computation. Results are written to Metric Result records (R6).
Portlets read R6 records as the current user. Because R6 View is granted to all roles, the read always succeeds. The metric value is the pre-computed result — it does not reflect any additional filtering by the viewing user’s role. The value is what the Controller signed off on.
When Tessera uses Saved Searches (N/search) rather than SuiteQL for a metric’s data path, those searches execute as the current user during computation. NetSuite’s permission model filters the search results to what the computation user can see. This is why the Tessera Administrator role must have appropriate GL read permissions configured during installation.
Tessera’s license is validated at runtime using an offline HMAC mechanism. The license key is stored in the Tessera Account Configuration custom record. A User Event script validates the key on every save of the Account Configuration record and updates the license_state field immediately.
At runtime, the portlet and Suitelet scripts check license_state before rendering. An expired or invalid license displays a degraded state message rather than metric data.
No license server call is made during normal operation. The HMAC validation is entirely local to the NetSuite account.
Environment separation: License keys encode the environment type (PROD or SBX). A production license key does not activate in a sandbox account, and vice versa. This allows customers to install and test Tessera in their sandbox without consuming production license terms.
Key replacement: A customer enters a new license key in the Account Configuration record. The User Event script re-validates immediately. No restart or administrator action beyond saving the record is required.
The CRL includes a health check that detects when a metric’s designated Domain Owner has been termed (their Employee record is inactive in NetSuite). Termed owner detection runs as part of the CRL fleet’s pre-computation health pass. Affected metrics are flagged in the Tessera Admin console for reassignment before the next scheduled computation cycle.