Salesforce Service Cloud interview questions

What a strong answer covers

• Case assignment rules evaluate on creation, and the first matching rule entry wins, so ordering the entries correctly matters as much as the criteria themselves.
• Assignment typically routes to a queue rather than to an individual, which keeps the work visible when someone is absent and allows either pull or Omni-Channel push from there.
• Omni-Channel then pushes queued work to agents based on presence status, capacity and, where configured, required skills.
• Cases created through the UI can bypass assignment rules unless the assignment checkbox is used, and inbound sources such as Email-to-Case or the API need this considered explicitly.
• A strong answer notes escalation rules handle what happens when nobody acts in time, that omni-channel behaviour and available routing types depend on the org's setup and licence, and that testing with realistic case data is what surfaces rule ordering errors.

Where people lose the point

• ×Assigning cases directly to individual users so work disappears when they are out.
• ×Forgetting that the first matching assignment rule entry wins and ordering entries carelessly.
• ×Overlooking that some creation paths do not trigger assignment rules unless explicitly told to.

What a strong answer covers

• With queues alone, agents pull work, so the mix that gets worked reflects agent choice and speed, and unappealing cases can sit unattended.
• Omni-Channel pushes work to agents based on presence status, configured capacity and priority, so the operation controls what gets worked next rather than the agent.
• Capacity can be weighted so synchronous work such as chat consumes more of an agent's capacity than an asynchronous email case, which is what makes multi-channel staffing workable.
• Skills-based routing matches work to specific capabilities, which is more precise than queue membership when language or product expertise matters.
• A strong answer mentions supervisor visibility of queued and in-progress work, and that specific routing options and configuration steps vary by release and licence.

Where people lose the point

• ×Describing Omni-Channel as just a fancier queue.
• ×Giving chat and email the same capacity weight.
• ×Building skills so granular that work cannot be routed to anyone.

What a strong answer covers

• Entitlements record what level of support a customer is eligible for, and are typically related to an account, contact, asset or service contract.
• An entitlement process defines the stages a case goes through against that commitment, and milestones within it represent the time-based targets such as first response or resolution.
• Milestones can carry actions: success actions when met, warning actions as the target approaches, and violation actions when it is breached, which is how escalation and notification are automated.
• Business hours and holidays attach to the calculation, so a milestone reflects working time rather than elapsed clock time where that is how the commitment was sold.
• A strong answer prefers this over building custom date fields and automation, because entitlements give reporting and timer behaviour out of the box, while noting that specific setup steps and features vary by release and licence.

Where people lose the point

• ×Rebuilding SLA timers with custom fields and scheduled jobs when entitlements exist.
• ×Ignoring business hours so overnight cases appear breached.
• ×Confusing the entitlement (what they are owed) with the entitlement process (how it is tracked).

What a strong answer covers

• Start with the article types and structure the team needs, and use data categories to organise articles by dimensions such as product or region so the same taxonomy drives both search and visibility.
• Define the lifecycle explicitly: who drafts, who reviews and publishes, how versions are handled, and how articles are archived when they go stale.
• Set visibility deliberately, since the same article set can be exposed to internal agents, to authenticated customers in an Experience Cloud site, and to the public, and not every article belongs in every audience.
• Wire it into the agent's workflow: Knowledge components in the console surface suggested articles against the case, and attaching articles to cases produces the data that shows which articles are actually resolving contacts.
• A strong answer treats the maintenance loop as part of the design, using article feedback and case-attachment data to find gaps and rewrite what keeps generating follow-ups.

Where people lose the point

• ×Building a data category structure so deep that nobody categorises correctly.
• ×Publishing internal-only wording to a public channel by not checking visibility.
• ×Treating Knowledge as a one-off migration with no review cycle.

What a strong answer covers

• Start from the tasks an agent repeats all day and design for the fewest clicks on those, rather than exposing every available field on the page.
• Use the console structure deliberately: tabs and subtabs for working several cases, the highlights panel for the facts an agent needs at a glance, and the compact layout to drive what appears there.
• Put related information where it is needed through related lists, Knowledge and history components, so the agent is not navigating away mid-conversation.
• Use quick actions and macros for repeated multi-step work, and path or guided components where the process benefits from a visible next step.
• A strong answer differentiates layouts by record type and by profile so different teams see the relevant view, and validates the design by watching agents work rather than by asking them in a workshop.

Where people lose the point

• ×Adding every field to the layout because someone might need it.
• ×Giving all teams a single layout regardless of what they handle.
• ×Designing the console without observing an agent handling real cases.

What a strong answer covers

• Assignment rules run at case creation and set the initial owner based on the first matching rule entry.
• Escalation rules act later on cases meeting age and criteria conditions, and can reassign, notify and mark the case escalated, with timing measured against business hours where configured.
• Flow covers everything those two do not: field updates, record creation, calling out to other systems, complex branching, and screen-based guidance for agents.
• The selection principle is to use the purpose-built declarative feature where it fits, because it is easier to maintain, understandable to admins, and reportable, and to move to Flow when the logic exceeds it.
• A strong answer mentions ordering and interaction problems: multiple automations acting on the same object need a coordination convention, and it is worth checking what already runs before adding another.

Where people lose the point

• ×Building assignment logic in Flow when assignment rules already cover it.
• ×Using escalation rules for logic that has nothing to do with time.
• ×Adding automation to an object without checking what already fires on it.

What a strong answer covers

• The default is declarative: assignment and escalation rules, entitlements, Omni-Channel routing configuration, and Flow cover a very large share of service requirements.
• Apex earns its place when the requirement exceeds declarative capability: complex bulk processing, intricate logic that would produce an unmaintainable flow, certain integration patterns, or callout and transaction control the platform tools do not offer.
• The cost is real: code needs test coverage, deployment discipline, and a developer to change it, which slows the admin-led iteration that service operations depend on.
• A useful test is whether an admin will need to change this in six months, and whether the declarative version would be genuinely unworkable rather than merely inelegant.
• A strong answer notes that Apex and Flow coexist in most orgs, and that governor limits and bulk behaviour matter whichever route is chosen.

Where people lose the point

• ×Reaching for Apex first because it feels more capable.
• ×Avoiding Apex on principle and building an unmaintainable flow instead.
• ×Ignoring the maintenance and deployment cost when recommending code.

What a strong answer covers

• Start from the decisions the manager makes: staffing, queue prioritisation, coaching, and where process or product is generating avoidable contacts.
• Operational views cover open case volume and age by queue and owner, backlog trend, and cases approaching or breaching milestones so action is possible before the breach.
• Quality and outcome views cover reopened cases, cases resolved with an article attached, case reason and root cause distribution, and customer satisfaction where it is captured on the case.
• Use report types and dashboards that match the audience, with agent-level detail for supervisors and trend views for management, and make sure filters reflect record types and business hours where relevant.
• A strong answer stresses that reporting depends on the data being captured consistently, so fields such as case reason need defined values and validation rather than free text, and avoids quoting target figures since these vary by organisation.

Where people lose the point

• ×Reporting on volume alone without aging or backlog trend.
• ×Building reports on free-text fields that cannot be grouped.
• ×Presenting benchmark targets that were not set by the business.

What a strong answer covers

• Inbound email to a routing address creates or updates a case, with the email body and attachments captured against it, and replies threaded back onto the same case.
• Threading relies on identifiers in the email, so replies from clients that strip or alter those, or forwarded chains, can create duplicate cases rather than continuing the original.
• Automated senders are a frequent problem: out-of-office replies and system notifications can create cases or reopen closed ones, so filtering and reopening rules need deliberate design.
• Consider the configuration options for how emails are received and processed, and check the limits and behaviours that apply to the org's edition and setup rather than assuming.
• A strong answer covers the operational rules around it: what happens on a reply to a closed case, how long a case stays reopenable, and how auto-response rules avoid replying to machines.

Where people lose the point

• ×Assuming threading always works and never checking duplicate creation.
• ×Letting out-of-office replies reopen resolved cases indefinitely.
• ×Configuring auto-response without excluding automated senders.