Horus Eye FAQ: what admins and security teams actually ask

Horus Eye is a Salesforce assessment and action-planning product from Kemisoft. It helps teams understand findings about their org, evaluate the options, and prepare remediation or migration work — with every finding tied to the evidence behind it. Today it has two specialist desks: NPSP → Agentforce Nonprofit migration, and Nintex^[2] DocGen estate health.

No. Detection uses predefined rules that look for known patterns and collect the evidence each one needs — not an AI exploring the org. When you ask for AI guidance on a finding, the selected evidence is supplied to the model; the model does not connect to your Salesforce org.

Yes. The consultation shows the proposed payload before you proceed, along with the credit cost — so you can read exactly what would be sent, and decline.

No. Findings come from predefined rules, each with the evidence it collected. AI assistance is optional, per consultation, and bounded by the finding and its options.

No, and it does not claim to. Each finding carries one of three approaches: automated (a supported operation applies the fix after your approval), guided (evidence-based options with steps you follow through), or manual (instructions for changes that need hands-on implementation).

No. The connection is read-only by default: scans read configuration and metadata. Write-back is a separate, explicit permission — off until you enable it, revocable at any time — and even then, supported changes happen only after your approval, one at a time.

The working policy is no direct writes to customer production environments. Changes are tested in a sandbox first; prepared scripts are then run in production by your team or delivery partner, inside your own change process.

No. A consultation uses the evidence already collected during the scan. To refresh the evidence, run a new scan — which also proves whether earlier fixes worked, because a fix counts as verified only when its rule goes silent.

The owner of a connected org can share it, and shared access includes the existing scan history. Note that independently connecting the same Salesforce org creates a separate connection with its own history — share the existing connection instead.

A repository connection is available, with more limited coverage than a live org connection — runtime information simply is not in a repo. It suits a first look at code and configuration under version control. Note that signing in with GitHub is only authentication: it does not give Horus Eye access to any repository. Connecting a repo is a separate, explicit step.

Sign in with Google, GitHub or e-mail. A Salesforce org connects through OAuth (refreshable) or a temporary session (typically around two hours before reconnection). OAuth is the comfortable default for ongoing work.

Findings with evidence, recorded decisions with their rationale, field mappings, generated migration scripts, validation that compares source and target on your own sandbox, and the delivery documents: strategy and architecture, design specification, action plan, a Jira-ready backlog, a mapping workbook^[1], readiness reports and bundled downloads.

Yes — that is the intended starting point. Authorize a read-only assessment, get the report, and decide what to do next with the evidence in hand. Talk to us about scope and authorization.