Design example
This page describes a proposed integration pattern. It does not report a verified production deployment or measured customer results.
The problem this pattern addresses
Application details can arrive in several fields and notes. A recruiter has to assemble the facts before deciding what to do next. A short draft summary could make that review easier, provided the original material stays available and the draft does not introduce facts or judgments.
The Salesforce record may be called a Lead, but the subject here is an applicant. This example does not rank candidates, infer suitability, recommend rejection or make an employment decision. The recruiter remains responsible for reviewing the application against the actual role requirements.
One bounded route from record to draft
- A permitted Salesforce action identifies a record ready for summarisation. Confirm the purpose and allowed fields before reading them.
- Make sends only the agreed fields to the model, together with record references that the reviewer can use.
- Claude returns a draft in a defined structure. Missing information stays missing; it is not filled with a guess.
- The integration checks the response and saves it as a draft, with a status, source references and generation time.
- A recruiter compares the draft with the application and records any correction before using it.
Keep generation separate from changes to the applicant’s hiring status. A successful API call is a technical event, not approval of the draft or permission to reject someone.
A schema checks shape, not truth
Anthropic supports structured outputs for supported models and configurations. That can help an integration consume predictable fields. It does not establish that a statement accurately reflects the applicant’s information. Validate the integration response and check the content against its sources.
Anthropic: structured outputs and their limits
A low temperature setting does not make a generative model a deterministic decision engine. The test set must include incomplete records, contradictory notes, unexpected text and content that tries to instruct the summariser. Treat all application content as data, never as instructions that grant access or trigger an action.
| State | What the reviewer sees |
|---|---|
| Waiting | No draft is available yet. The original application remains accessible. |
| Draft ready | The summary, its sources and the time it was generated. |
| Needs attention | The specific issue, such as missing input or an unreadable response. |
| Reviewed | Who checked the draft and whether it was corrected. |
Design retries and updates deliberately
Use a stable job identifier so a retry cannot create several competing summaries. Record the source version or update time. If the applicant’s information changes during processing, flag the draft as potentially stale instead of silently overwriting the newer record.
A failed generation should leave the existing application intact. Limit retries, give the operator a useful error and provide an explicit way to try again. Avoid putting sensitive application text in operational logs.
What a pilot would need to demonstrate
Use approved synthetic or suitably de-identified examples first. Have recruiters compare each draft with its source and identify omissions, unsupported statements and time spent correcting it. Include people and application formats that the production process expects to handle.
Measure review effort and factual accuracy against an agreed baseline. Decide the acceptable error types and stopping conditions before extending the pilot. This page supplies no speed, cost or hiring-quality benchmark.
Check the foundations for an AI workflow
Discuss a similar workflow
Bring a description of the process, the systems involved and one example of where work gets stuck. We can use discovery to establish the requirements, dependencies and next step before preparing a solution and estimate. Please leave private customer, applicant and patient records out of the website enquiry.