A recruiter opens a candidate under one role and asks an AI assistant to save a handoff note. The text includes a concern from another interview process. The recruiter expects the current hiring team to see it. That expectation needs checking before anything is written. In Ashby, a note belongs to the candidate profile rather than a specific job consideration. The job selected on screen does not make the note private to that role.
This guide explains the native note behavior and a recommended design for custom AI preparation. The approval record, audience checks and write journal below are engineering controls to build around an integration. They are not claims that Ashby automatically supplies those controls for every note.
Start with the profile-level audience
Ashby's candidate feed tracks events, notes, feedback, emails and other activity. The feed generally shows information relevant to the selected job consideration. Notes have an important separate rule. Ashby explicitly says they are tied to the candidate profile and do not currently support role-specific visibility and notification limits.
Users following the candidate may include hiring team members from earlier or closed considerations. Ashby warns that those users may be able to see notes and receive notifications. A custom assistant should therefore ask which information belongs on the shared profile, rather than assuming every observation from the current role belongs there.
Separate viewing, adding and private access
Ashby's access-role settings distinguish Can See Notes from Can Add Notes. Adding notes requires the viewing permission. The add permission is separate from Can Add/Edit Candidates. That distinction matters when designing a recruiter workflow that should allow an operational handoff without granting broad candidate editing.
The candidate feed guide also provides an Is note private? option. It describes private notes as visible to Organization Admins and Elevated Access users with Admin Private access to the job, department or location. Private does not mean visible only to the author or to one selected recruiter. Check the effective roles for the actual people involved.
| Question | Native distinction | Integration decision |
|---|---|---|
| Can the person read ordinary notes? | Can See Notes | Check the reviewer's effective access |
| Can the person add a note? | Can Add Notes depends on Can See Notes | Keep note creation separate from profile editing |
| Is the text sensitive? | Private notes use a restricted audience | Confirm that audience before saving |
| Is an API key writing? | candidate.createNote requires candidatesWrite | Review API scope separately from human roles |
Build a narrow source packet
Before generating text, define the purpose of the note. A sourcing handoff, an interview follow-up and an internal operational reminder have different evidence needs. Include the candidate identity, the relevant job context, approved source excerpts and the intended audience. Leave unrelated history out of the model input unless it is authorized and necessary.
Mark each excerpt with its origin and date. Keep a recruiter's statement distinct from an interviewer's observation and from an AI inference. If the assistant cannot support a sentence from the packet, remove it or flag it for review. A plausible summary should not become a new factual claim on the candidate profile.
Cross-role context deserves an explicit decision. Suppose a candidate was considered for two teams with different requirements. A gap against one role's requirement should not become an unqualified statement about the person. Preserve the role and source, or leave the statement out of a general handoff.
Review the text and the destination together
A reviewer should see the exact candidate, proposed note, source references and visibility choice in one place. Show the job consideration as context while clearly labeling the write as profile-level. A generic approval button that hides the destination is not enough for this workflow.
- Confirm the candidate identity against a stable identifier, not a name alone.
- Read the evidence supporting each material sentence.
- Check whether the text is appropriate for the proposed audience.
- Decide whether mentions or tasks are necessary.
- Approve the final text and intended write destination together.
Make edits invalidate the previous approval. If the assistant regenerates the note, changes its audience or switches candidate, ask the reviewer to examine the new proposal. This is a recommended integration rule. It prevents an earlier approval from silently authorizing different content.
Handle mentions and tasks deliberately
Ashby's manual note flow supports mentioning users. The recruiter can select Create a task for the tagged user and set a date. That task appears on the tagged user's Home page after the note is added. A summary integration should not assume that mentioning someone is merely decorative text.
For an initial rollout, keep generated handoff notes free of mentions and tasks unless the reviewer explicitly selects them. Test the final native behavior separately. Do not infer that the note API supports every option in the manual interface, or that pasted mention text creates the same task behavior.
Verify the write before retrying
Keep a custom journal of the approved request, candidate identifier, proposed content and observed outcome. After submission, verify the resulting note using an authorized read or the native interface. If the response is lost, record an uncertain result and reconcile it before sending again. A timeout does not prove that no note was created.
Do not assume createNote provides a duplicate-prevention key unless the current contract explicitly establishes it. The same principle applies to edits. Ashby's feed guide says a user cannot edit a note on behalf of another user. Design correction ownership before rollout rather than assuming a recruiter can rewrite every integration-created note.
Test visibility with real access roles
Use test candidate data and representative accounts before enabling production writes. Include an ordinary reviewer, a user without note access and a user with the relevant private access. Where possible, include a follower from a closed consideration. Check both the note view and notification behavior without exposing real sensitive content.
Common mistakes are treating a job filter as a security boundary, assuming private means author-only, copying restricted evidence into ordinary text and retrying uncertain writes blindly. Also test your own review screen, exports and logs. Restricting the native note does not automatically restrict copies made by the custom application.
How Remqa approaches Ashby note workflows
Remqa builds AI agents for recruiting teams with explicit source, review and write boundaries. A useful starting scope is one note type with a known audience and an operator who owns corrections. Expand only after the team can verify the result and explain who can see it.
For the integration side, review our Ashby API permissions guide. If your team wants to remove repetitive preparation without delegating candidate judgments, bring a sample workflow to a recruiting workflow discussion. Start with the audience decision, then build the note writer.