Sample Org Briefing — a fictional org (Meridian Mutual) with synthetic metadata, so you can see the shape of the deliverable.  ← Back to KENSEDA
◭KENSEDA Meridian Mutual prod Scan #48 · sample

Org Briefing

What this org actually does — ranked by blast radius, with the evidence path behind every claim.
Fixable — attention needed

Three blast-radius risks, concentrated on two objects.

Nothing here is on fire, but two of your busiest objects each carry a save-order conflict where the last automation to write wins. Both are provable from the metadata and both are one focused change to close.

Org health
72/100
▼3 since scan #47
78
Objects
41 custom · 37 standard
24
Flows
active only
96
Apex classes
18 triggers
31
Automations
active only
15
Validation rules
active only

Situation board

5 situations, ranked by severity
Evidence path
BillingService.calculateDues()—CONTAINS→ for (Invoice__c inv : invoices)—CONTAINS→ SELECT … FROM Payment__c
How KENSEDA knows
MATCH (m:ApexMethod)-[:CONTAINS]->(l:ApexLoop)-[:CONTAINS]->(q:SoqlQuery) WHERE m.apiName = 'BillingService.calculateDues' RETURN q.line, q.soql // → line 88, 1 row

Consequence: reachable from the nightly DuesBatch at 200-record chunks. Move the query above the loop or bulkify with a map keyed by parent Id.

The three writers, in save order
trigger OpportunityStageSync (before)then workflow WF_Stage_Revertthen flow Opportunity_Route_Score (last)
How KENSEDA knows
MATCH (w)-[:WRITES_FIELD]->(f:Field {apiName:'Opportunity.StageName'}) RETURN labels(w)[0] AS writer, w.apiName, w.saveOrderPhase ORDER BY w.saveOrderPhase // → 3 rows

Consequence: the workflow's revert is dead code whenever the flow fires. Decide the single owner of StageName; the order-of-execution simulator shows the exact override point.

Evidence path
LedgerRecalcTrigger (after update)—INVOKES→ LedgerRecalcHandler.recalc()—DML update→ Ledger_Entry__c
How KENSEDA knows
MATCH (t:ApexTrigger)-[:INVOKES]->(:ApexMethod)-[d:DML {op:'update'}]->(o:SObject) WHERE t.sobject = o.apiName AND 'after update' IN t.events RETURN t.apiName, o.apiName // → 1 row, no guard node

Why conditional: re-entry only compounds past a batch threshold — marked conditional because KENSEDA states what the metadata proves can happen, not that it fired at runtime.

Evidence path
PSG Sales_Full—CONTAINS→ MutingPermSet Sales_Mute—MUTES→ Modify All: Account, Contact, Opportunity
How KENSEDA knows
MATCH (g:PermissionSetGroup)-[:CONTAINS]->(m:MutingPermissionSet)-[:MUTES]->(p) RETURN g.apiName, m.apiName, collect(p.name) // → effective, not nominal

Consequence: access reviews that read the group's nominal grants over-report. The effective-access model resolves the mute so the audit is honest.

Evidence path
Flow Case_Auto_Assign—HAS_ELEMENT→ Assignment: Assign_Owner—SETS→ $Record.OwnerId = "005..."
How KENSEDA knows
MATCH (f:Flow)-[:HAS_ELEMENT]->(a:FlowAssignment)-[:SETS]->(v:FlowValue) WHERE v.isHardcodedId = true RETURN f.apiName, a.name, v.value // → 1 row

Consequence: not urgent, but flagged so a sandbox-to-prod deploy doesn't route every new Case to a stale owner.

⊘

What this briefing does not claim

Every situation above is derived from static metadata — the structure of your Apex, flows, objects, and permissions. KENSEDA states what the metadata proves can happen; it never asserts that an automation fired on a specific record or measures runtime data volume. Items marked conditional depend on inputs (batch size, record state) the metadata cannot fix. That boundary is the point: no guesses ship as facts.

KENSEDA — See what your org actually does. Sample · synthetic org · not a real client Get an audit of your org →