Salesforce for executive search with durable history and controlled reporting

For search partners and operations teams managing candidate history, confidential mandates and client updates in an existing Salesforce org. Adapt the model to your search product and privacy requirements.

An executive-search system needs to hold two views at once: the current position of a particular search and the longer relationship with each candidate. It also needs to control which parts of that knowledge can be shared.

A candidate can be interested in one role, unavailable for another and worth approaching again later. Recording one global “candidate stage” loses that context. Putting every detail into an unrestricted relationship note creates a different problem: useful history can become inappropriate disclosure.

The design should make current work easy to understand while preserving the source, date and access boundary of the underlying evidence.

Model the relationship and the engagement separately

Start with these concepts, reusing managed-package objects when they fit:

A consideration record connects a candidate with a search. It can hold presentation date, current stage, assigned researcher, next action and disposition. Decide how to represent re-entry after withdrawal so a new conversation does not erase the earlier outcome.

Opportunity can represent the commercial sale, the search engagement, or a carefully designed combined lifecycle where that fits the business. A dedicated engagement object is another option. The deciding factors are forecasting, fees, delivery milestones, access and reporting, rather than a universal prohibition on using Opportunity.

Choose lookup or master-detail relationships deliberately. Inherited sharing and cascade deletion may be unsuitable for confidential or retained search history. Native roll-up summaries also depend on the applicable master-detail relationship; a lookup-based model needs another aggregation mechanism. Salesforce relationship considerations and roll-up summary fields

Keep candidate stages and engagement milestones distinct

The search might be at “Client interviews underway” while one candidate is being researched, another is awaiting feedback and a third has withdrawn. Store each candidate's progression on the consideration record and the engagement's overall state separately.

Define stages by observable events. “Presented” should have an agreed meaning and supporting date. An interview's scheduled date passing does not prove it happened. Track completed, canceled and no-show outcomes where relevant.

Practices may need different stage labels. Record types, dependent picklists or a governed configuration model can support variations, but cross-practice reporting still needs consistent definitions. Map local stages into a stable reporting category and version material changes. Routine configuration ownership and release approval should remain explicit.

Preserve history behind a concise current summary

Give the partner a short current summary: interest, latest meaningful interaction, next action and owner. Link it to the dated interactions supporting it.

For example, the summary might say “Open to regional CFO roles; follow up after current year-end close.” The supporting interaction records who said this, when, and which search it concerned. When preferences change, update the summary and retain the earlier interaction under the firm's retention policy.

Do not repeatedly overwrite the only conversation record. Equally, do not preserve unnecessary sensitive detail forever. Define correction, retention and deletion processes. Standard Activities, notes or a purpose-built interaction object can be useful depending on searchability, reporting, access and retention requirements; they are not inherently invisible to reporting.

Separate observed facts, candidate statements and internal judgments. Record when information was last verified. A structured field becomes misleading when an old inference is presented as a current fact.

Design confidentiality across every access route

Private organization-wide defaults are a starting point for restricted engagement records. Grant access deliberately to the search team and review membership changes. Verify the candidate, consideration, interaction and file records as well as the engagement itself.

Private does not mean invisible to everyone outside a named team. Hierarchy access and broad View All or Modify All permissions may grant additional access. Custom objects allow control over hierarchy access, with documented caveats including related Activities. Salesforce role and hierarchy guidance

Use field-level security for information a role must not read or edit. Layouts and report filters are presentation choices. Also inspect integrations, exports, files and custom components. For Apex and Flow, assess the actual execution context, API version and explicit access settings rather than assuming that everything runs with the viewer's permissions. Secure Apex guidance

An executive dashboard needs particular attention. A static dashboard can display information using another running user's access. Test what the actual audience sees. Dashboard data visibility

Treat the client update as an approved disclosure

A curated report type helps define the fields available to a report. It is not an unbypassable confidentiality boundary across the org: someone with wider underlying access may use another report, an API or a different interface. Salesforce custom reports

Build a defined client-update dataset and generation process. Include only fields approved for that audience, require the appropriate review, and retain the version that was sent. A separately permissioned client-facing record or document may be appropriate; its generation and access controls need implementation and testing.

Illustrative example: a confidential CFO search has three candidates currently on its client-approved slate.

These rows illustrate audience separation, not a rule that all listed fields are always shareable. The engagement terms, candidate permissions and firm's policy determine the actual disclosure. Counts and omitted identities can also reveal information in a small search, so review the whole output.

Prove the design with a small end-to-end pilot

Use fictional records to run one search from mandate through closure. Include a returning candidate, a changed preference, a withdrawal, a team-member departure and a correction after a client update was generated.

Test as a researcher on the search, a researcher outside it, a partner, an integration user and any external audience. Check direct record links, search results, reports, dashboards, exported documents and attachments. Removing someone from the team should trigger an access check, not just remove their name from a page.

Reconcile stage totals against the underlying consideration records and confirm the client update's date and version. Measure preparation and review effort if efficiency is a goal; establish the baseline before claiming a time saving.

The strongest starting point is one complete, reviewable search workflow. It establishes whether candidate knowledge survives the engagement, confidentiality holds across access routes and the partner can produce a trustworthy client update.

Review your search-to-client-update workflow

Talk through your executive-search workflow with Gosai Digital. Bring an anonymized update template, current stage definitions and the access boundaries your firm needs. Please omit real candidate identities and confidential mandates from the initial contact form.