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.
Ready to Dive In?
Installing Pharos TritonWhy 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.
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.
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, 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.
That same builder scales up to partial-DML capture, integration payloads, and governor-limit tracking — all covered in Core Concepts. 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 — so it survives the hops between contexts without you threading it everywhere.
Spans for structure. On top of correlation,
spanId/parentSpanIdadd 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.
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 — 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.
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:
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.
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, 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 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 that produced it in the first place.
Primary beneficiaries: developers, admins, platform/IT teams
Last updated