AI conversations in the Salesforce world tend to orbit around models, features, and integrations. But working admins usually ask a much more practical question: what can I actually use AI for, day to day?
One strong answer is Claude Code — an agentic coding assistant that works with Salesforce DX projects. You don't need to write Apex to get value from it. Here are seven admin tasks where it can take on the repetitive research, comparison, and drafting work, leaving you to make the decisions that need real Salesforce judgment.
A few ground rules first: always test changes in a sandbox before touching production, and check your org's policy on AI tools reading metadata and data — anything Claude reads leaves your org for processing by the model provider (Anthropic, Amazon Bedrock, or Google Vertex AI, depending on your setup). Authenticate the Salesforce CLI against a sandbox (sf org login web --instance-url https://test.salesforce.com) and run Claude Code from an SFDX project.
1. Audit custom fields with no detected references
Leftover custom fields from old projects pile up. Ask Claude to retrieve custom fields on Account and Opportunity and flag those with no detected references across page layouts, Lightning record pages, field sets, list views, formulas, validation rules, Flows, Apex, email templates, report types, and your specified report folders — presented in a table, marked as review candidates, not confirmed unused.
Your review step: reports are tricky, because the Metadata API doesn't support wildcard report retrieval, so Claude can only scan the folders you include. Also check outside the retrieved metadata — integrations, external reporting tools, data loads, managed packages, workflow rules, and old Process Builder automation. Confirm with the field owner before removing fields from layouts or deleting them; Salesforce offers no deactivate option for custom fields.
2. Generate permission set documentation
When an org has dozens of permission sets, tracking who has what is slow. Have Claude retrieve the permission set metadata and query PermissionSetAssignment records (filtering out profile-owned sets), including permission set groups, member sets, and muting permission sets, then write a Markdown doc per set covering object permissions, system permissions, and assigned users.
Your review step: spot-check a few sets — especially sensitive ones like Modify All Data and View All Data — against Setup. Remember the doc won't show complete effective access: profiles and session-based permission sets aren't included.
3. Review Flows for missing fault paths
Record-triggered and screen Flows with Create, Update, Delete, or Get Records elements — or action elements — that lack fault connectors will show users ugly unhandled fault messages (and send error emails). Ask Claude to review the Flows in your project, list elements that support fault connectors but have no explicit fault path, explain the potential failure for each, and suggest an error-handling approach.
Your review step: decide which recommendations fit your org's error-handling standards, then build and test both success and failure scenarios in a sandbox.
4. Draft validation rules from business requirements
Stakeholders speak plain English; validation rules need formulas. Ask Claude to draft the rule — formula, error message, and error location — from a requirement like "prevent closing an Opportunity as Closed Won unless Amount is greater than zero and a primary contact is set, with a custom-permission bypass."
Your review step: verify API names against your org. If you're checking for a primary contact, Opportunity's standard ContactId field (the ID of the contact marked Primary in Opportunity Contact Roles) may do the job without a new lookup field — though validation rules can't directly query Opportunity Contact Role records. Test valid, invalid, and bulk scenarios, including data loads and integrations, and use a custom permission rather than a profile for the bypass.
5. Compare metadata between sandbox and production
Environments drift. Ask Claude to retrieve the same package.xml manifest from sandbox and production into separate folders, compare them, summarize the differences, and flag anything that exists only in production.
Your review step: the comparison only covers what's in your manifest. Components that exist only in production might be direct hotfixes, managed-package content, or Salesforce features — bring genuine production changes back into the sandbox or source control before deploying so you don't overwrite them.
6. Write SOQL queries for data cleanup reports
Standard reports don't always answer data-quality questions. Ask Claude to write and run a SOQL query — e.g., Contacts created in the last 90 days with no email and no recorded activity (using LastActivityDate), exported to CSV.
Your review step: cross-check the record count with a quick Salesforce report, confirm your org's activity data before treating results as final, and remember query results sent to the AI tool leave your org — avoid sensitive fields unless your policy allows.
7. Prepare deployment packages with a change summary
Release documentation eats time. Ask Claude to identify the week's changed components from Git history, build a package.xml manifest, run a validation-only deployment against production (sf project deploy validate), and write a plain-language release summary for business users.
Your review step: source tracking and Git history only go so far — provide the component list yourself when they don't. Review the summary from a business user's perspective, and be careful with permission sets: a deployment must include full permission set metadata (API 40.0+) to avoid overwriting permissions.
Conclusion
Claude Code won't replace admin judgment — but it can absorb the repetitive research, comparison, querying, and drafting work while you focus on the decisions that genuinely need your Salesforce expertise. Pick one task from this list, try it in a sandbox, review the output, and expand from there.
Top comments (0)