- product
Audit log as a product feature
Why the audit log is on Odexy's product page, not its compliance page. What customers actually do with it.
Every Odexy action writes a row to audit_log. The fields are mundane: actor_type, actor_id, session_id, input_hash, output_hash, ip, user_agent, the action name, the diff of state changed.
You'd think this is a compliance feature — useful when an auditor shows up, irrelevant in day-to-day operations. We thought that too, at first. Customers proved us wrong.
How customers actually use the audit log
Three patterns from design-partner interviews:
1. "What happened to this deal?"
A 12-person sales team has a deal that went from "Negotiation" back to "Discovery" overnight. In a standard CRM, you'd start asking people. In Odexy, you open the deal's audit timeline and see exactly: at 11:47 PM, the AI agent (delegated by Maria) advanced the deal stage based on the customer's reply email. At 12:03 AM, Maria's mobile session reverted it.
The audit log is a debugger for human + AI workflow. It replaces 15 minutes of Slack questions with 3 seconds of scrolling.
2. "Did the AI do something I didn't authorize?"
This is the AI-trust use case we expected. Customers want to see what the AI is doing on their behalf. Odexy's audit log shows every AI call, the user who delegated, the input hash + output hash, and the resulting state change.
Operators check this daily for the first month after enabling AI, then weekly thereafter. The presence of the log builds trust; the absence of bad behavior keeps it.
3. "Why was this charge made?"
Finance teams use the audit log differently — they look at the trail from invoice → payment → revenue → GL entry. Each step is one audit row. If a reconciliation discrepancy shows up at month-end, the finance team walks the chain backward: GL entry references the payment; payment references the invoice; invoice references the deal; deal references the rep. The pre-Odexy version of this is a Slack thread asking five people across three tools.
Why this matters for the product
We initially designed the audit log for compliance. SOC 2 Type II readiness will probably reference it. GDPR-grade data subject requests reference it. HIPAA mode tightens it. All true.
But the daily value isn't compliance — it's operational visibility. Odexy's customers run their businesses with one audit log across CRM, HR, Sales, Recruitment, Payroll, Accounting. The compliance value is downstream; the operational value is immediate.
Two architectural decisions enabled this:
1. One audit_log table across every module. Not "CRM activity log" + "HR activity log" + "Payroll log." One table, partitioned by month, queryable across modules.
2. Audit on every action, not just destructive ones. Even reads can be audit-logged (we toggle this per-tenant for HIPAA mode). The benefit is the gapless timeline — you can replay an entire user session.
What the alternative looks like
Most multi-tool SaaS stacks have logs somewhere — Stripe has dashboard logs, Salesforce has activity history, HubSpot has timeline events. Each is silo'd to its own product. Each has its own schema. Each has its own retention policy. Joining them across tools requires a SIEM or a data warehouse.
In Odexy, the join is SELECT * FROM audit_log WHERE org_id = ? AND created_at >= ? ORDER BY created_at. One query. Every event. Across every module.
What we don't claim
The audit log isn't a SIEM. It's not built for security event correlation or threat hunting. We don't ship dashboards over it the way Splunk does. For tenants that need SIEM-grade analysis, we export to one (forwarder support is on the Phase 3 roadmap, currently a manual API export).
What we do claim: it's the timeline of your business. And because it's one table across the suite, it's the timeline you can actually read.
— The Odexy team