Freshdesk Product Expert for Admins common mistakes
Freshdesk Product Expert for Admins · Understand the traps and how to avoid them.
Treating Dispatch'r, Observer, and Supervisor as interchangeable 'automation' features and picking the wrong engine for a scenario (e.g., using Supervisor to auto-assign a new ticket, or Dispatch'r to notify a manager when a ticket ages).
All three live under the same Workflows/Automation menu and all read as 'if this then that'. Candidates memorise that they exist but not the trigger model: Dispatch'r fires on ticket creation/update events to act on the ticket itself, Observer monitors tickets for elapsed-time and update conditions to trigger notifications/actions, and Supervisor watches agent performance metrics (e.g., overdue, pending, unresolved counts) to alert supervisors. The exam deliberately builds scenarios that hinge on which trigger is available.
What to do instead
Build a one-page decision table before the exam: trigger type (event vs. elapsed time vs. agent metric), what object it evaluates (ticket vs. agent), and typical action (assign/update vs. notify/escalate). For each practice scenario, first ask 'what is the trigger?' and only then choose the feature. Remember Supervisor is about agent workload, not ticket content.
Assuming a role's permission set alone determines what an agent can see and do, ignoring group scoping and the ticket-scope settings (global vs. group-restricted visibility).
The role editor lists granular permissions (edit, delete, assign, view reports) that look complete, so candidates answer as if permissions were the whole model. In reality an agent's effective access is the intersection of role permissions, group membership, and the account-level ticket scope/visibility configuration. Questions describing an agent who 'has the permission but still cannot see the ticket' are testing exactly this gap.
What to do instead
For any access question, enumerate three layers: (1) role permissions, (2) group membership and whether the role is group-scoped, (3) account-wide visibility settings. Practise reasoning about least-privilege: an agent in Group A with a group-scoped role should not see Group B tickets even with broad permissions. Verify with the 'what does this agent actually see' framing.
Designing SLA policies around the wrong metric or clock - mixing first-response and resolution targets, or forgetting that business hours vs. calendar hours and time-zone settings change when a target actually breaches.
SLA configuration screens combine target type, time metric, business-hours calendar, and applicability conditions, and candidates skim them. They then answer 'the ticket breaches at 5pm' when the policy runs on a 24x7 calendar, or apply a first-response SLA to a resolution question. Business-hours misconfiguration is the single most common source of wrong breach times.
What to do instead
For every SLA scenario, write out four things before answering: which target (first response / next response / resolution), which clock (business hours calendar or 24x7), which time zone, and which conditions make the policy apply. Confirm the priority ordering of multiple matching policies. Re-derive breach times by hand on a small example rather than pattern-matching.
Confusing escalation behaviour with SLA behaviour - expecting an SLA policy itself to reassign a ticket or notify a manager, or expecting an escalation rule to change the SLA target.
SLA policies and escalations are configured in adjacent areas and both involve time thresholds. Candidates conflate 'target time' with 'action on breach'. In practice SLA policies define targets and breach states; escalations (and time-based automation rules) define what happens when conditions like approaching-breach or unresolved-for-N-hours are met. The exam tests whether you know which component performs the action.
What to do instead
Separate the concepts cleanly: SLA = measurement and target; escalation/time-based rule = action (notify, reassign, change priority). When a question asks 'how do you make sure a manager is alerted before breach', the answer involves an escalation/automation rule referencing the SLA state, not editing the SLA itself. Memorise which actions each component can and cannot perform.
Answering custom-field questions without accounting for field type constraints, form placement, and downstream dependencies (required fields, field visibility per form, and effects on reporting/filters).
Candidates learn that custom fields exist and can be added to forms, then assume any field can do anything. But choice fields with dependencies, mandatory-on-close rules, and field-to-form mapping have real constraints, and changing a field later (e.g., altering choices) can orphan data and break reports. Scenario questions about 'why can't agents close this ticket' or 'why is this field missing on the portal form' hinge on these details.
What to do instead
For each custom-field question, check: field type and its limits, which forms include it, whether it is required at a specific stage (e.g., on resolution), and whether reports/filters depend on it. Know that portal-facing forms and agent-side forms can differ. Treat field changes as data-migration events, not cosmetic edits.
Treating email configuration as plug-and-play - ignoring forwarding vs. mailbox polling, SPF/DKIM implications, and how reply threading and the support address affect ticket creation.
Email setup looks like entering an address and a password. Candidates skip the delivery model: whether mail is forwarded to the helpdesk address or fetched from a mailbox, how sender authentication affects deliverability, and how the system matches replies to existing tickets (via ticket ID in subject/headers). Questions about duplicate tickets, replies creating new tickets, or mail landing in spam test these mechanics.
What to do instead
Learn the email ingestion pipeline: inbound path (forwarding vs. mailbox fetch), authentication records (SPF/DKIM) that determine deliverability, and threading rules (reply-to address and ticket-ID matching). For each email scenario, ask 'where does the message enter, and how is it matched to a ticket?' Practise diagnosing duplicate-ticket and threading failures from those two levers.
Assuming sandbox is a live mirror or that changes in sandbox automatically propagate to production, and underestimating what cannot be tested or migrated.
Candidates hear 'sandbox' and assume a safe clone with one-click promotion. In reality sandbox is a separate environment refreshed from production data, and configuration changes made there do not automatically flow back - some elements must be recreated or exported/imported, and data like tickets/contacts behave differently. Questions about safe testing and deployment test this expectation gap.
What to do instead
Know the sandbox contract: it is a refreshed copy for testing, not a deployment pipeline. Before answering, identify whether the item is configuration (may be reproducible) or data (not promoted). For 'how do you safely test this automation' questions, the correct reasoning involves building and validating in sandbox, then recreating the configuration in production, not assuming sync.
Confusing API keys, webhooks, and app integrations - e.g., using a webhook where an API call is needed, or assuming an API key inherits an admin's full permissions regardless of the acting user context.
All three appear under Integrations/Apps and all 'connect systems'. Candidates blur direction (inbound vs. outbound), trigger model (event push vs. request/response), and authentication scope. The exam asks which mechanism fits a scenario, and whether an API key's privileges are bounded by the user who created it.
What to do instead
Classify by direction and trigger: webhook = outbound event push to a URL; API = request/response access to data with key-based auth; app = packaged integration with its own auth flow. Remember API keys act with the permissions of the associated user, so scope matters. For each scenario, ask 'who initiates, and in which direction does data flow?'
Designing reports/dashboards without aligning the metric definition to the underlying data model - e.g., reporting on 'resolved' tickets without filtering status/time window correctly, or mixing agent-level and group-level aggregation.
Report builders offer many dimensions and filters, and candidates pick plausible-sounding ones without checking what each counts. 'Tickets resolved this week' can mean resolution-date-based or status-change-based depending on configuration, and agent vs. group rollups can double-count or miss tickets. Dashboard questions test whether you can map a business question to the correct measure and filter set.
What to do instead
For each reporting question, define the measure (count, average time), the population (which tickets pass the filters), and the time basis (created vs. resolved date). State these explicitly before choosing a report type. Practise translating business questions ('how fast are we responding by group?') into measure + filter + grouping, and check for double-counting in group rollups.
Treating canned responses and solution articles as the same self-service content, and misjudging where each is surfaced (agent-side insertion vs. portal/self-service deflection) and how placeholders/variables behave.
Both store reusable text, so candidates assume interchangeability. But canned responses are agent-inserted macros (with placeholder substitution tied to ticket/contact data), while solution articles are customer-facing knowledge base content used for self-service and deflection. Questions about reducing ticket volume vs. speeding agent replies, or about why a placeholder rendered blank, depend on this distinction.
What to do instead
Map each to its audience and channel: canned response = agent efficiency, inserted into a reply, uses placeholders resolved at send time; solution article = customer self-service, organised in categories/folders, indexed for portal search. For 'reduce inbound volume' choose self-service content; for 'speed up agent handling' choose canned responses. Verify placeholder data exists on the ticket before expecting substitution.