Frequently Asked Questions

Five signs indicate an org audit is overdue. First, reports show data that leadership questions ("these numbers can't be right"). Second, automations fire at unexpected times or produce duplicate records. Third, new hires take more than two weeks to learn the system. Fourth, nobody can explain what a specific Flow or Process Builder automation does. Fifth, your org has more than 20 custom objects and no data dictionary.

A Salesforce org audit reviews five areas: data quality (duplicate rates, field completeness, validation rule coverage), automation health (Flow logic, trigger conflicts, governor limit proximity), security model (profile and permission set configuration, field-level security gaps, sharing rule accuracy), technical debt (unused fields, deprecated automations, sandbox drift), and documentation gaps.

CCC's audits take 1-2 weeks and produce a prioritized action plan, not a 100-page report. The deliverable tells you what to fix first, what can wait, and what to stop doing.

The Salesforce Trust Layer is a set of security controls that sit between Salesforce data and external AI models. When Einstein, Copilot, or Agentforce sends data to an LLM for processing, the Trust Layer handles three phases.

In the Prompt Journey, the system retrieves relevant CRM context (dynamic grounding) and then masks sensitive data: PII, payment card numbers, and protected fields are replaced with placeholders before anything leaves Salesforce. During Response Generation, the masked prompt reaches the LLM through a unified gateway. Salesforce maintains zero data retention agreements with providers like OpenAI and Azure, meaning the provider cannot store your prompt data or use it for training. In the Response Journey, the AI output passes through toxicity detection (which assigns a confidence score logged to an audit trail) and then de-masking (where original data replaces the placeholders).

The Trust Layer matters because Salesforce AI features send your data to external systems for processing. Without these controls, a user asking Copilot to "summarize this account's history" could inadvertently send Social Security numbers or health records to a third-party model.

The critical distinction: the Trust Layer prevents data leaks. It does not prevent bad decisions. Your organization still needs governance to decide who can use AI features, which objects AI can access, and what happens when AI produces incorrect results.

This is a design decision that depends on complexity, volume, and maintenance requirements.

Use Flow when: the automation involves standard CRUD operations (create, read, update, delete), the logic has fewer than 10 decision branches, the team maintaining the org does not include developers, and the trigger volume is moderate (under 10,000 records per batch). Flows are declarative, meaning admins can read and modify them without writing code. For AI agent triggers specifically, Flow is appropriate when the agent performs simple record lookups, field updates, or notification sends.

Use Apex when: the logic requires complex data transformations, the trigger handles high-volume operations (over 10,000 records), the automation needs precise error handling beyond Flow's fault connectors, or the agent trigger interacts with external APIs that require custom authentication. Apex gives you direct control over governor limit consumption and transaction management.

The wrong answer is "always use Flow because it's no-code." A Flow that handles a complex multi-object transaction with nested loops and subflows can be harder to debug and maintain than the equivalent Apex class. The right answer depends on who will maintain it and how complex the logic is.

CCC's rule of thumb: if the automation takes more than 15 minutes to explain to a senior admin using the Flow canvas, it probably belongs in Apex.

A complete Salesforce RFP should cover eight areas: current state (what systems you use today, how many users, what works and what doesn't), desired outcomes (what "done" looks like in business terms, not technical specifications), scope boundaries (what is included and what is explicitly excluded), timeline expectations (hard deadlines, soft preferences, dependencies on other projects), budget range (a range is better than no number, because it helps consultants self-select), evaluation criteria (how you will compare proposals, weighted by priority), required deliverables (documentation, training, post-launch support expectations), and team availability (who from your side will participate and how many hours per week).

The most common RFP mistake is specifying solutions instead of problems. "We need a Flow that sends emails when opportunities close" is a solution. "Sales reps don't follow up after deals close, and we lose 20% of upsell opportunities" is a problem. The second version gives the consultant room to recommend the right approach, which may not be the one you assumed.

For someone with no technical background, reaching job-ready competence in Salesforce Administration takes 8 to 12 weeks of focused study (15-20 hours per week). This covers the Salesforce Administrator certification exam objectives: data management, security and access, automation, customization, reports and dashboards, and app deployment.

CCC's training program at NYU Tandon School of Engineering follows this timeline and has achieved an 80% job placement rate across 160+ students. The program is designed for career changers and non-technical staff who need practical skills, not academic theory.

The Salesforce Administrator certification exam itself requires understanding of approximately 65 topics across 7 domains. Pass rates for first-time test takers average 60-65% according to community surveys. With structured preparation, that rate rises to 80%+.

The most effective study approach: hands-on practice in a free Salesforce Developer Edition org, Trailhead modules for concept learning, and practice exams for test readiness. Reading documentation alone is not sufficient. Salesforce is a hands-on skill.