Catching Salesforce Custom Field Drift With the Postman AI Engineer

Postman's AI Engineer identified and fixed a Salesforce custom field drift issue that caused a POST /leads request to fail with a REQUIRED_FIELD_MISSING error after a required custom field Lead_Source_Detail__c was added in the Salesforce org. The AI Engineer proposed coordinated updates to the frontend code, the collection request, and the OpenAPI specification, and generated a pull request with new tests to prevent future drift. The fix was merged after review, resolving the outage and downstream dependencies.

Catching Salesforce Custom Field Drift With the Postman AI Engineer Anyone who uses Salesforce has been there. New leads stop showing up on the sales dashboard. The API returns a 400. The frontend doesn’t rendering half the rows. Someone in the Salesforce org had added a custom field, and enabled it as required on the create form. Our POST /leads request suddenly returned a validation error we weren’t handling, and the GET /leads response now included a field the frontend didn’t recognize. Two teams, one CRM, and a shape change no one told anyone about. I traced the root cause with the Postman AI Engineer and then built a Postman AI Automation so it couldn’t happen again. This post walks through both. Why Salesforce custom fields break so quietly The Salesforce sObject Create endpoint https://developer.salesforce.com/docs/atlas.en-us.api rest.meta/api rest/dome sobject create.htm is where you POST new records for any object, including standard objects like Leads. When someone in the org adds a required custom field from the Salesforce UI, every future POST to that endpoint has to include the field or Salesforce rejects the create with a REQUIRED FIELD MISSING validation error. The problem is that the shape of an accepted payload changes silently. There’s no webhook that fires when someone adds a field. One day a required custom field lands on Lead and every downstream consumer that doesn’t send it starts getting 400 Bad Request back with REQUIRED FIELD MISSING . If you’ve been through this before, you know the flavor: the error names the exact field, but by the time it hits your logs, production is already broken. Fixing the broken request with the AI Engineer I keep a Postman Collection for our Salesforce integration in a workspace we share across backend and frontend. The failing POST SObject Create request was there. From the Slack, I typed a short prompt to the AI Engineer: Why is this request failing? The AI Engineer inspects the request, response, and environment variables in context. Within about 30 seconds, it told me: - The response returned REQUIRED FIELD MISSING referencing Lead Source Detail c . - Our request body had no Lead Source Detail c key, and the example response saved on the collection didn’t include it either. No one had updated the request when the field was added on the org side. - Our OpenAPI specification https://spec.openapis.org/oas/latest.html in Spec Hub didn’t include Lead Source Detail c either. Then it offered to fix all three places in one pass: the frontend code that was breaking on the new field, the failing collection request, and the OpenAPI specification in Spec Hub. I said yes. A few minutes later, a pull request landed in our GitHub repo bundling the frontend fix, the updated collection request, the spec update, and a pair of new tests to catch this class of drift on future runs: js pm.test "Response does not indicate a missing required field", = { const body = pm.response.text ; pm.expect body .to.not.include "REQUIRED FIELD MISSING" ; } ; pm.test "Lead payload includes all required custom fields", = { const requiredCustomFields = pm.environment.get "required custom fields" ; const requestBody = JSON.parse pm.request.body.raw ; JSON.parse requiredCustomFields .forEach field = { pm.expect requestBody .to.have.property field ; } ; } ; I reviewed the diff, confirmed the field was in the right place in each artifact, and merged the PR. That fixed the outage, and all of its downstream dependencies in one shot. If you’ve never used the AI Engineer this way, the short version is that it can read the request, the response, the collection, the environment, and the specification, and it can propose coordinated changes across all of them. That’s what made this useful. I wasn’t switching between four tabs guessing at what had drifted. The AI Engineer had all of it in context, and the fix shipped as one atomic PR. Keeping it in sync with Agent Automations Fixing the outage once was good. Making sure it couldn’t happen again was the point. That’s what Agent Automations are for. To set one up, click the home button in Postman, open Agent Automations, and type a prompt for the AI Engineer. For this project, I gave it: Update the frontend based on the changes to my collections That’s the whole configuration. Every time a pull request opens against our repo, the Automation runs the AI Engineer on the diff, cross-references the collections in the shared workspace, and updates the frontend to match. If a request in a collection gains a new required field, the frontend types and form components pick it up. If a field is removed, the corresponding usage in the frontend gets removed. Everything stays aligned without me having to think about it. Phrasing the prompt as an outcome “update the frontend based on the changes to my collections” rather than a rigid rule lets the AI Engineer figure out what “based on” means for each PR. Sometimes that’s a type change. Sometimes a new form field. Sometimes a validation update. I don’t have to enumerate every case up front. The Automation drops its changes as a follow-on commit on the same PR before merge, so I still get to review the diff. What I don’t have to do anymore is remember to make it. Gotchas I hit along the way A few things caught me on the way through this. Field-level security can still block a required field The Create endpoint’s error response tells you a field is required, not whether the OAuth user your integration authenticates as is allowed to write it. If your service account doesn’t have field-level security enabled for a new custom field, the field shows up in REQUIRED FIELD MISSING errors but writes still fail with INVALID FIELD FOR INSERT UPDATE even after you include it. Have the Automation check both the create response and the user’s field-level permissions if you want a complete picture. The Salesforce sObject Create reference https://developer.salesforce.com/docs/atlas.en-us.api rest.meta/api rest/dome sobject create.htm walks through the error codes. Regenerating client code isn’t free When the Automation regenerates frontend types after a collection change, the DTOs pick up the new field. If your codebase has strict null checks, adding an optional field is fine, but adding a required field surfaces as compile errors across every component that constructs the DTO. That’s the point, but it’s worth telling your team that the tradeoff of catching drift early is more compile-time noise to work through. Automations run in the Postman Cloud Agent by default If your Salesforce instance sits behind a private network, use the Postman Desktop Agent or Postman Browser Agent https://learning.postman.com/docs/getting-started/basics/about-agents/ instead. The Automation definition doesn’t change; only where the request runs changes. Keep each Automation focused I tried to build one Automation that handled every downstream artifact: frontend, backend, docs, and examples. It was slow, and when it failed I couldn’t tell which artifact had drifted. Splitting it into one Automation per artifact type made the failure messages readable and the runs faster. Run it against your own Salesforce org If you want to reproduce this, you’ll need: - A Postman account https://identity.getpostman.com/signup with the AI Engineer available on your plan - A Salesforce sandbox where you can add and remove custom fields - A connected app in Salesforce https://help.salesforce.com/s/articleView?id=connected app create.htm with OAuth 2.0 client credentials - An OpenAPI 3.0 or 3.1 specification for your Salesforce integration in Spec Hub Fork the Salesforce Platform APIs public workspace https://www.postman.com/salesforce-developers/salesforce-developers/overview to get a working Salesforce collection to start from. Import it into your workspace, generate an OpenAPI specification from the collection https://learning.postman.com/docs/design-apis/collections/generate-specifications , and then create an Automation from the prompt above with your own repo and workspace wired up. Open a PR that changes the collection and watch the Automation reconcile the frontend on the same PR. I’ve been running the same pattern for HubSpot custom properties and a couple of internal services where the schema changes without a version bump. It works the same way anywhere the source of truth is a live schema you can query. Resources Postman AI Engineer overview https://learning.postman.com/docs/agent-mode/overview Postman Agent Automations https://learning.postman.com/docs/agent-mode/skills Sync collections and specifications reference https://learning.postman.com/docs/design-apis/sync-specifications-reference Generate an OpenAPI specification from a collection https://learning.postman.com/docs/design-apis/collections/generate-specifications Salesforce sObject Create endpoint https://developer.salesforce.com/docs/atlas.en-us.api rest.meta/api rest/dome sobject create.htm OpenAPI Specification 3.1 https://spec.openapis.org/oas/latest.html Writing test scripts in Postman https://learning.postman.com/docs/writing-scripts/test-scripts/ The Postman CLI reference https://learning.postman.com/docs/postman-cli/postman-cli-overview/