Build "Salesforce Field Explorer" — a polished single-page web app for exploring and auditing any Salesforce org's metadata. It makes Salesforce easy to navigate and clean up. It helps you: Explore objects and fields without digging through Setup. Discover fields you didn't know existed — search in plain English and let AI surface the right ones. Find empty objects and fields (no records / never populated) so you can audit and declutter. See where a field is actually used — flows, layouts, reports, Apex — and which fields are safe to retire. Read descriptions, picklist values and formulas at a glance, with CSV export. Setup — ask me before building: Connect Salesforce, and ask which org URL to target (e.g. https://yourcompany.my.salesforce.com) and API version (default v62.0). Connect an AI model (Anthropic or OpenAI) for the natural-language field search. Architecture: one React single-page app for the UI, plus small backend route steps (one per Salesforce/AI call) that the app fetches from. Keep all credentials in the connectors — never in code. Use the supplied org URL/API version everywhere; don't hardcode. Salesforce endpoints (REST + Tooling API): Objects: GET /sobjects/ merged with Tooling SELECT QualifiedApiName, Label, Description FROM EntityDefinition (the global describe silently omits some custom objects). Fields: Tooling SELECT QualifiedApiName, Label, Description, DataType FROM FieldDefinition WHERE EntityDefinitionId = '<Object>'. Picklist values & formulas: GET /sobjects/<Object>/describe → read picklistValues and calculatedFormula. Empty fields: SELECT COUNT() FROM <Object> for the total, then batched COUNT(<field>) aggregates; for types COUNT() rejects (booleans, long text, etc.) fall back to WHERE <field> != null LIMIT 1. Empty objects / record counts: GET /limits/recordCount?sObjects=… (bulk, one call) with a SELECT COUNT() FROM <Object> fallback for custom objects it doesn't track. Field usage ("where used"): Tooling MetadataComponentDependency, query RefMetadataComponentId = <field id> — convert the 15-char FieldDefinition.DurableId to the 18-char id first. Group by MetadataComponentType, build deep links back into Salesforce, and collapse Flow versions to the active/latest one. AI field search: send the field list to the connected model and constrain it to only return fields that exist in the list (also filter out any invented apiName server-side). API limits & pagination (apply everywhere): Always follow SOQL/Tooling pagination — read nextRecordsUrl/done and use queryMore, except for objects like EntityDefinition that don't support it (use keyset pagination on DurableId). Never assume a single page. Respect Salesforce rate/concurrency limits: cap concurrent requests (~6–10 in flight), batch where the API allows (bulk recordCount, multi-COUNT() aggregates), throttle per-record loops (e.g. the field-usage analysis), and handle 429 / REQUEST_LIMIT_EXCEEDED / query timeouts gracefully with a clear message. Known caveats — handle gracefully, never crash: The integration user often can't read CustomField via the Tooling API, so created-by/created-date may be unavailable — show a note instead of failing. Field-level security: fields hidden from the integration user won't appear in describe, so picklist/formula lookups should say "not readable by this credential," not "not found." Some fields/objects can't be counted or filtered (long text, compound, or no read access) — show "—" / "couldn't determine" honestly. Standard objects/fields usually have no description and no tracked metadata dependencies — that's expected, not an error. UI: clean and modern with a light/dark toggle, CSV export on each view, clear back navigation, and plain-language notes wherever a Salesforce limitation applies. Tools used: Salesforce (REST + Tooling API), Anthropic or OpenAI (AI field search), React