> For the complete documentation index, see [llms.txt](https://triton.pharos.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://triton.pharos.ai/triton-best-practices.md).

# Best Practices & Standards

Opinionated, field-tested standards for rolling out Pharos Triton logging across Apex, LWC, and Flow, and keeping it consistent as your org grows.

The [Core Concepts](/core-concepts.md) tell you *how* the Triton API works. This section is about *how to use it well* — the judgment calls that separate logs you're glad you have from noise you'll end up filtering out.

It's written for the person standing up Triton across a real org: architects and senior developers who have to make logging consistent across a dozen teams, a pile of legacy triggers, and every technology Salesforce throws at them (Apex, LWC, Flow). The advice here is opinionated on purpose. When there's a right answer, we'll give it to you.

Everything is on the **2.0 static, builder-first API** — `Triton.log(Triton.t...)`, no `Triton.instance`. If you're coming from 1.x, read [Migrating from Triton 1.x to 2.0](/migration.md) first, then come back here.

## The short version

If you read nothing else, internalize these five:

* **Build every log the same way.** Set a [template](/triton-best-practices/templates-and-builder-pattern.md) once per unit of work, then log from `Triton.t`. Consistency is what makes logs searchable.
* **Buffer the routine, publish the critical.** Queue progress logs and [flush at boundaries](/triton-best-practices/buffering-and-flushing.md); send exceptions with `logNow` so you never lose the one that mattered.
* **Log at the right level and let metadata decide.** Don't gate logs behind `if (debug)` — pick a [level](/triton-best-practices/log-levels-and-usage.md) and tune volume through `Log_Level__mdt`.
* **Correlate across hops.** Start a [transaction](/triton-best-practices/transaction-management.md) at the entry point and carry it through LWC → Apex → Flow so one user action reads as one trace.
* **Use the real** [**taxonomy**](/triton-best-practices/taxonomy-and-standards.md)**.** Category/Type/Area from the enums, extended deliberately — never ad-hoc strings.

## How this section is organized

Read it in order the first time; each page assumes the one before it.

| Page                                                                                       | What it covers                                                                           |
| ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| [Core Principles](/triton-best-practices/core-principles.md)                               | The handful of ideas the rest of the section is built on, plus the master Do/Don't list. |
| [Log Levels: When to Use What](/triton-best-practices/log-levels-and-usage.md)             | Picking `ERROR` vs `WARNING` vs `INFO` vs `DEBUG`, and tuning verbosity per environment. |
| [Templates & the Builder Pattern](/triton-best-practices/templates-and-builder-pattern.md) | Setting a template per unit of work and logging from `Triton.t`.                         |
| [Buffering & Flushing](/triton-best-practices/buffering-and-flushing.md)                   | Conserving platform events without losing critical logs.                                 |
| [Transaction Management](/triton-best-practices/transaction-management.md)                 | Stitching logs together across LWC, Apex, and Flow.                                      |
| [Implementation Patterns](/triton-best-practices/implementation-patterns.md)               | Copy-ready patterns for triggers, batches, queueables, REST, schedulers, LWC, and Flow.  |
| [Context & Related Objects](/triton-best-practices/context-and-related-objects.md)         | Making each log carry enough context to debug from.                                      |
| [Taxonomy & Standards](/triton-best-practices/taxonomy-and-standards.md)                   | Designing a Category/Type/Area vocabulary that scales.                                   |
| [Exception Handling](/triton-best-practices/exception-handling.md)                         | Turning caught exceptions into actionable, correlated error logs.                        |
| [Standards Enforcement](/triton-best-practices/standards-enforcement.md)                   | Code-review checklists and CI guardrails that keep standards from rotting.               |
| [Legacy Code Logging Rollout](/triton-best-practices/legacy-migration.md)                  | Adding observability to old, poorly-understood code without breaking it.                 |

{% hint style="info" %}
**Why any of this matters.** A single user action might cross an LWC, an Apex controller, a Flow, and a callout. When it breaks at 2am, the difference between a five-minute fix and a five-hour investigation is whether those five layers produced one coherent, well-labeled trace — or five disconnected piles of text. The standards here exist to make the first outcome the default.
{% endhint %}