> 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/readme.md). # About Pharos Triton Just as the mighty Triton delivered important messages from the deep, Pharos Triton sends you crucial insights from the depths of your Salesforce automation. {% embed url="" %} *Pharos Triton Intro* {% endembed %} *** ## Ready to Dive In? {% content-ref url="/pages/3FhR0oQeNx4BVfQjJlTN" %} [Installing Pharos Triton](/installing-pharos-triton.md) {% endcontent-ref %} ## Why Logging? If you've spent any time on the Salesforce platform, you know that, by default, it doesn't generate logs in its standard setup. You also know that exception emails and debug logs don't quite cut it when you're trying to run and troubleshoot an org — the former is unmanageable, the latter is short-lived and limited. For all its complexity, the platform offers no built-in answer to a common engineering problem: **what went wrong, when, and how.** Troubleshooting a non-trivial automation without logs is like stumbling around a dark room hoping to trip over the problem and magically land on a solution. It's slow, frustrating, and hazardous to one's mental state. So many engineers took matters into their own hands: if Salesforce won't keep logs for us, we'll keep them ourselves. That's how logging frameworks were born, and over the years they've become something thousands of developers and admins across the ecosystem quietly rely on every day. ## Pharos vs Pharos Triton You might be wondering how Pharos and Pharos Triton relate. If it's all Greek to you, allow us to elaborate.

The Mighty Triton - Messenger From the Depths Of the Sea

### Pharos Pharos is a Salesforce-native observability platform, composed of several layers: tracking, awareness, action, collaboration, and resolution. It does far more than create logs — it's an entire suite that runs on log data: notifications, analytics, grouping, monitoring, and issue tracking. Pharos can even generate log records automatically from certain Salesforce system events, and there's quite a bit of data in those. But system events aren't the only way to feed the platform. That's where Triton comes in. ### Pharos Triton Pharos Triton is the ingestion component of the broader Pharos platform. It's responsible for capturing log data from your own automation — Apex, LWC, Flows, custom REST APIs, even emails. In the diagram below, note the section on the bottom right in blue. That's Pharos Triton.

Components of the Pharos Observability Platform and Pharos Triton

## What Exactly Does Pharos Triton Do? Simply put, Pharos Triton is a logging framework for all things Salesforce. It lets you create logs from your automation — code or declarative — where a single log record can carry any useful data point: debug info, warnings, integration payloads, governor-limit stats. If you can capture it, you can log it. The mechanics are deliberately simple. As of [2.0](/release-notes/2.0.md), Triton exposes a **static, builder-first API**: you describe a log with a fluent builder and hand it to `Triton`, which keeps the running state of your transaction for you. {% code lineNumbers="true" %} ```apex Triton.info(Triton.t .area(TritonTypes.Area.Opportunities) .summary('Recalculated rollups')); ``` {% endcode %} That same builder scales up to partial-DML capture, integration payloads, and governor-limit tracking — all covered in [Core Concepts](/core-concepts.md). Because Triton persists logs through platform events, it can also act as a connector: ingest data from an external system like MuleSoft, shape it into a log record, and feed it into the rest of the Pharos platform. ## One Transaction, End to End A single click in the UI almost never stays in one place. A user presses a button in a Lightning Web Component, that calls an Apex controller, the controller commits a record, and the DML fires off an autolaunched Flow. Four contexts, one intent — and, without help, four disconnected piles of logs. Triton's defining capability is turning those piles into **one story**. It correlates logs across LWC, Apex, and Flow using a shared **transaction id**, so when you open a log in Pharos you can follow the whole chain from the button press to the Flow that failed three hops later. * **A transaction id that travels.** The id can ride along explicitly (pass it from LWC into Apex) or automatically through the [platform cache](/end-to-end/transactions-and-cache.md) — so it survives the hops between contexts without you threading it everywhere. * **Spans for structure.** On top of correlation, `spanId` / `parentSpanId` add parent-child nesting *within* a transaction, turning a flat list of logs into a tree: the click, the backend call it triggered, and the step that call ran inside. * **Errors that come along for free.** Unhandled Flow errors are captured and correlated automatically — no fault path required — so nothing in the chain goes dark. {% content-ref url="/pages/yOdpD3VSNncFGaebUTPF" %} [End-to-End Logging](/end-to-end.md) {% endcontent-ref %} ## Built for AI-Assisted Development Instrumenting an existing codebase by hand is the least glamorous job in engineering. Triton 2.0 ships alongside a set of [**instrumentation skills**](/instrumentation-skills.md) — portable, agent-agnostic playbooks that any AI coding agent (Claude Code, Cursor, Copilot, and others) can follow to add convention-following logging to your Apex, LWC, and Flows. Point an agent at a file — or an entire org — and it reads the code, infers the right structure, and proposes instrumentation, always behind a **human-in-the-loop diff review** so nothing is written until you approve it. It's the tedious 90% of a logging rollout, automated, without giving up control. And instrumentation is only half the story. Because Triton produces **structured, classified, correlated** log data — not free-text `System.debug` noise — it gives AI tooling a clean, machine-readable signal to reason over when analyzing failures and behavior across your org. {% content-ref url="/pages/PW2a4ljzASpISTDPbZF3" %} [Instrumentation Skills](/instrumentation-skills.md) {% endcontent-ref %} ## IT-Friendly: The First Step Toward OpenTelemetry Salesforce is too often an observability island, cut off from the tracing standards the rest of IT runs on. Getting off that island starts with capturing your automation in a shape the wider world understands — and that's exactly what Triton does. Its tracing model — a **transaction id** that correlates a whole operation, plus **spans** and **parent spans** that add parent-child structure — maps directly onto the vocabulary platform teams already speak: | OpenTelemetry concept | Triton 2.0 equivalent | | --------------------- | ------------------------------------------------------- | | **Trace** | The transaction id correlating one end-to-end operation | | **Span** | `Span_Id__c`, set via `.spanId(...)` | | **Parent span** | `Parent_Span_Id__c`, set via `.parentSpanId(...)` | Instrumenting with Triton is the concrete first step of the OpenTelemetry journey: you capture your telemetry once, at the source, in a model that already speaks OTel's language — so the data is ready to travel beyond Salesforce when you are. {% hint style="info" %} **A foundation, not the finish line.** Triton isn't an OpenTelemetry SDK, and it doesn't need to be — its job is to produce OTel-shaped telemetry at the source, which is the hard part. From there, bridging that data into a broader OpenTelemetry pipeline is a natural next step on the Pharos platform. See [Spans & Distributed Tracing](/end-to-end/spans-and-tracing.md) for the full mapping. {% endhint %} ## How Does Pharos Triton Compare to Other Logging Frameworks? On features and functionality, Pharos Triton is a top-tier logging framework. If you're familiar with the Nebula logger library, you'll find Triton just as powerful and easier to navigate and extend. Like Nebula, it uses platform events to persist logs and offers ready-made interfaces for Apex, LWC, and Flow. What really sets Triton apart is that it isn't just a log utility — it's the front door to a full observability platform. You get automated error capture, fingerprinting and categorization, issue tracking, and pre-built dashboards to analyze log data, plus Slack and Teams notifications. And unlike Nebula, Pharos is a commercial solution, so you get real support for any issues you hit — even on the free tier. ## Is Pharos Triton Free? The short answer is yes. The Pharos platform [is offered in multiple editions](https://pharos.ai/pricing), including a free tier, and the Triton component works with any of them. It's just a matter of choosing how much observability functionality you want. You can absolutely run Triton on Pharos Free with no loss of logging capability. ## Logging Use Cases The world of logging is vast, and what you can achieve is really only limited by your imagination. That said, here are the common directions teams take on their logging journey. ### Troubleshooting Troubleshooting is about finding the root cause of a problem you know is happening: something isn't working, but you don't know where it originates. The range of "troubles" one can "shoot" is enormous — from user errors to automation failures — and the idea is the same throughout: the data in your logs tells you why the execution went the way it did. **Primary beneficiaries:** developers, admins, and ultimately end users ### Profiling Sometimes there's no outright failure — just a performance drag on an LWC page, a Flow, or an Apex trigger, or you're creeping toward (or hitting) governor limits. Here it's invaluable to see resource consumption broken down by each step: SOQL queries, CPU time, execution time, callout time, and more. **Primary beneficiaries:** developers, admins, end users ### Tracing In more advanced territory, you find yourself navigating complex, multi-step transactions — a screen Flow that commits a record, which fires an Apex trigger, which launches an autolaunched Flow. Tracing records every step so you can confirm the order of operations is what you expect. With Triton's transaction id and spans, that trace spans LWC, Apex, and Flow — and maps cleanly onto [OpenTelemetry](/end-to-end/spans-and-tracing.md) concepts your platform team already knows. **Primary beneficiaries:** developers, admins, platform/IT teams ### Auditing Some organizations have strict compliance requirements around key areas — a financial institution, say, tracking every step of a complex financial exchange. But auditing is valuable even without a compliance mandate: it's how you confirm that what you *expect* to happen actually does. A closed opportunity that kicks off external provisioning, order creation, and outbound comms deserves an audit trail for every step — it's how you catch silent disconnects before they become disasters. **Primary beneficiaries:** business, operations, legal ### User Experience This one is about adoption. Are your users reaching the end of your screen Flows? Where are the time-consuming steps in that custom LWC they live in all day? Where do people drop off in your application process? Analyzing the log trail of real user interactions surfaces answers that are otherwise unavailable — or extremely hard to get through traditional UX studies. **Primary beneficiaries:** UX designers, admins, end users ### AI-Assisted Analysis Structured logs aren't just for humans reading a dashboard. Because Triton output is classified and correlated, it's a clean signal for AI tooling — feeding automated triage, anomaly spotting, and root-cause analysis, and closing the loop with the [instrumentation skills](/instrumentation-skills.md) that produced it in the first place. **Primary beneficiaries:** developers, admins, platform/IT teams