Horus Eye · How It Works
From finding to evidence-backed decision
Understand what matters in your Salesforce org — and take the next step with evidence. This page is the whole workflow: how a Salesforce org analysis becomes findings, how an investigation turns a finding into a decision you can defend, and what happens — and doesn’t happen — when a change is applied.
The workflow, end to end
Seven Stages- Connect your org. A read-oriented connection to a production org, sandbox, or demo org — sandboxes are a sensible place to start.
- Scan and analyze. Horus Eye reads the org’s available metadata and builds findings — conditions worth looking at — grouped by issue, each carrying the evidence it was built from and the scan timestamp it reflects.
- Prioritize. Findings are ranked so the ones that affect security, data integrity, and change safety surface first — instead of a flat list of everything.
- Investigate with Consult Horus. For findings that need more than the evidence card, an investigation examines the actual component in your org’s context and explains why it matters here.
- Decide. Some findings have a supported next action; some need an owner’s answer first; some are deliberate design worth recording as accepted. The decision — and who made it — is part of the record.
- Act. Where a change is supported for that specific target, review the exact change and approve it. Where it isn’t, follow org-specific guidance with the steps, owner questions, and verification criteria spelled out.
- Verify and retain history. Applied changes are checked against the org, and the finding history keeps what was found, decided, and done — so the next scan starts from knowledge, not from zero.
What Consult Horus adds
Investigation, Not GuessworkIt reads the real component
Not a generic article about “sharing settings” — the actual object, rule, credential, or report behind the finding, with its captured evidence and dependencies.
It explains “why here”
The same condition can be harmless in one org and serious in yours. Consult Horus connects the finding to your context: package ownership, platform constraints, who and what is affected.
It knows what it doesn’t know
Good investigations narrow uncertainty instead of inventing certainty. Where the answer depends on business intent or usage the scan can’t see, it asks the owner question rather than papering over it.
Why not just ask a general AI? A general assistant can suggest possibilities — often good ones. What it can’t do is ground the advice in your org’s captured evidence, check it against what the platform actually permits for that component, and connect it to a supported, reviewable next step. That combination — org context, investigation, reviewable action, accountability — is the product. And a recommendation, from either, is not proof of a completed fix: Horus Eye treats execution and verification as their own steps, not as implied by the advice.
The kinds of work it covers
Six LanesPermissions & security
Who can see and change what — and whether grants that bypass sharing are deliberate. “Which of these broad grants would we re-approve today?”
Automation & dependencies
What fires when a record changes, in what order, and what else depends on it. “What breaks if we retire this field?”
Reports & data quality
Reports built on fields that no longer earn their place, duplicates, and data nobody fully trusts. “Which of these six near-identical reports do people actually use?”
Integrations & credentials
Named credentials and endpoints, including ones with no scanned references left. “Is anything still using this connection — and who owns the answer?”
Package readiness
Managed-package components, upgrade posture, and the boundary between what you can change and what the vendor controls. “Is this ours to fix, or theirs?”
Maintainability
The slow accumulations — ownership concentration, profile sprawl, configuration nobody documented — that make every change request slower. “What would a new admin need three months to learn?”
What Horus Eye can inspect vs. what it can change
Decision & ControlInspect: broadly
Analysis reads the org’s available metadata and evidence — objects, automation, permissions, reports, integrations, packages — and keeps the scan timestamp visible so you know what a finding reflects.
Change: deliberately
Execution is narrower than analysis, on purpose. A change is offered only where the operation is supported for that specific target — eligibility depends on things like whether a component is standard, custom, or vendor-managed. You review the exact change before it is applied, and the result is checked afterwards. Horus Eye doesn’t claim a change is risk-free or universally reversible — it shows you what it intends to do, does only that, and tells you what was verified.
The deeper protections — what the AI can and cannot see, how requests are audited, and why AI is off by default — live on the Trust Layer page.
Four workflows, honestly told
Grounded ExamplesReviewing sharing-bypass grants
A permission set grants object-level access that bypasses sharing. Horus Eye shows which grants exist and where; Consult Horus explains what each one means for this object and who holds it. You decide which grants are deliberate. For eligible targets, the narrowing change is presented for review and applied on approval — then checked against the org.
A credential with no scanned references
A Named Credential shows zero captured references. That’s a lead, not a verdict — the scan can’t see every runtime caller. The investigation lays out what is known, what the dependency graph may miss, and the owner question that settles it, before anyone touches a connection an integration might quietly depend on.
Comparing reports before retirement
Six near-identical reports; the real question is which filters and consumers differ. Horus Eye assembles the evidence and guidance for the comparison; the retirement call stays with whoever owns the reporting — recorded, with reasons, in the finding history.
A managed-package issue
Some findings land inside a vendor’s package. Horus Eye identifies the ownership boundary and routes you to supported package configuration or a vendor conversation — instead of pretending a direct edit is available.
Evidence has a shape — and edges
Honest Decision SupportHorus Eye is useful because it is explicit about what its evidence covers. Four edges worth knowing:
Findings reflect a scan in time
Every finding carries its scan timestamp. If the org changed since, re-scan before acting on close calls.
The dependency graph has limits
Captured references are evidence of use; their absence is not proof of disuse. Runtime callers and external consumers can sit outside the scan’s view — the guidance says so when it matters.
Managed packages are a boundary
Vendor-controlled internals are analyzed from the outside. Horus Eye tells you when the next step belongs to the vendor.
Some answers are yours alone
Whether a grant is deliberate, a report is still needed, or debt is a rational trade — those are business decisions. Horus Eye frames them well; it doesn’t fake them.
Frequently asked questions
Straight AnswersDoes Horus Eye change my org automatically?
No. It analyzes and recommends; changes happen only where an operation is supported for that specific target, and only after you review and approve the exact change. Everything else is guidance you carry out yourself.
What if it cannot apply a fix?
Then it says so and gives you the org-specific steps instead: what to check, the questions only an owner can answer, and what to verify afterwards. Standard objects, managed packages, and business decisions are the common reasons a finding ends in guidance rather than execution.
What does Consult Horus inspect?
The actual component behind the finding, in context: its evidence, captured dependencies, package ownership, and platform constraints — ending in a recommendation for the available route. A recommendation is not a completed fix.
Can it work with managed packages?
It identifies packaged components and respects the ownership boundary: guidance points to supported package configuration or vendor review, not to edits the platform doesn’t allow.
How are changes approved and checked?
You see the exact intended change before approving it, and the result is checked against the org after it is applied. Verification confirms what was checked — the finding history records the rest.
What does a “finding” mean?
A condition worth looking at, with evidence attached — not automatically a defect. Some findings are deliberate design to record as accepted; some need usage evidence; some are calls only the business can make.
Can I start in a sandbox?
Yes — and it’s a good idea. Connect a sandbox or demo org first, see the workflow end to end, then decide about production.
Protected AI — the Trust Layer
Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.
See your own org this way
The fastest way to understand the workflow is to run it: connect read-oriented, scan, and open your first finding’s evidence.
Try Horus Eye Talk to an Architect All Horus Eye pages