Freshdesk Product Expert for Admins: Canned Responses

What this domain covers

Canned Responses tests reusable reply content: personal, group, and global visibility, folders, placeholders, attachments, permissions, and usage reporting. The exam focuses on consistency and avoiding accidental disclosure.

Core rules and concepts

• Canned responses can be personal, shared with a group, or global. Visibility determines who can insert and edit them; a global response is not the same as a personal draft.
• Responses support folders for organization, attachments, and placeholders such as requester name, ticket ID, agent name, and custom fields.
• The reply editor usually supports a shortcut such as / to search and insert a canned response. Inserting a response copies its content into the reply; later edits to the canned response do not change already-sent replies.
• Placeholders resolve at insertion or send time. If a field is empty, the placeholder may render blank, so test with real ticket data.
• Permissions should limit who can edit global responses; otherwise one agent can change customer-facing wording for everyone.
• Usage reporting helps identify stale or overused responses, but it depends on agents actually inserting them rather than pasting text.

Worked example

A billing team creates a global refund response with placeholders for the customer’s name, order number, and refund amount. An agent inserts it into a ticket where the order number custom field is empty. The name fills correctly, but the order number renders blank, so the customer receives an incomplete instruction. The reasoning: placeholders are only as good as the ticket data behind them. The fix is to require the order field on the form or add a manual check before sending.

Traps that cost marks

• Editing a global response without checking which teams rely on it.
• Using placeholders for fields that are optional or often empty.
• Attaching files that contain internal notes or outdated pricing.
• Assuming a personal response is visible to the whole group.
• Letting agents paste over canned responses so usage reports undercount.

Solution Articles and Self-Service Content

What this domain covers

Solution Articles and Self-Service Content tests the knowledge base: category and folder structure, article visibility, approval workflow, languages, SEO, portal search, suggested articles, and feedback loops.

Core rules and concepts

• Solutions use a hierarchy of categories, folders, and articles. Plan the structure around customer tasks, not internal team names, so portal search and browsing work.
• Visibility can be public, logged-in customers only, or agents only. A private category hides its articles from the portal even if an individual article looks published.
• Articles move through draft, review, and published states where approval workflow is enabled. An article that is not published will not appear in self-service search.
• Multi-language knowledge bases require translated articles or a defined fallback; a missing translation should not silently show the wrong language.
• SEO fields, article titles, and summaries affect portal search and external search results. Suggested-article features in the ticket form depend on relevant, current content.
• Article feedback helps identify gaps, but it needs an owner who reviews low ratings and stale content.

Worked example

A billing team writes a refund article under Billing > Refunds and sets the category to public. The article is approved but left in review instead of published, so customers cannot find it in the portal. An agent sees it in the internal knowledge base and assumes customers can too. The reasoning: agent visibility and portal visibility are separate; approval state controls publication. The fix is to publish the article and verify it in an incognito portal search.

Traps that cost marks

• Leaving an article in review and expecting portal search to index it.
• Putting sensitive runbooks in a public category.
• Creating duplicate articles for the same task, splitting search results.
• Ignoring language fallback and showing English to non-English customers.
• Treating article feedback as a vanity metric instead of a content backlog.

SLA Policies

What this domain covers

SLA Policies tests how Freshdesk defines first-response and resolution targets, applies policies by priority or other criteria, counts time against business hours, and surfaces breaches and reminders.

Core rules and concepts

• An SLA policy contains targets such as first response time and resolution time, and can include next-response targets where available. Targets are usually expressed in hours or minutes.
• Policies are applied by criteria such as priority, group, company, source, or ticket type. Policy order matters when multiple policies could match; the first applicable policy wins unless the design explicitly changes priority or group.
• Business-hour policies count only in-calendar time; calendar-hour policies count continuously. The same 8-hour target can mean very different due times.
• Some configurations pause the resolution clock while a ticket is Pending, waiting on the customer. If pause is not enabled, Pending time still counts.
• SLA reminders and escalations notify before or after breach. They are separate from the target itself and must be configured deliberately.
• The applied SLA and its due times are visible on the ticket; reports show met, breached, and running SLAs.

Worked example

An Urgent policy sets a 2-hour first response and an 8-hour resolution, using business hours. A ticket arrives at 10:00 and the first public reply is at 11:30, so first response is met. The resolution clock runs until 18:00, pauses overnight, and resumes the next working day. If the ticket is set to Pending and pause is enabled, the resolution clock stops until the customer replies. The reasoning: target, calendar, and pause behavior all affect the due time.

Traps that cost marks

• Assuming the first matching policy is always the intended one when policies overlap.
• Changing priority after creation and not checking whether the SLA policy changes.
• Counting a private note as first response.
• Forgetting that Pending only pauses the clock if configured to do so.
• Testing SLA with calendar hours when production uses business hours.

Escalations and Time-Based Rules

What this domain covers

Escalations and Time-Based Rules tests how Freshdesk detects aging tickets and escalates them. The focus is on Supervisor-style time conditions, escalation levels, actions, scheduling, and business-hour behavior.

Core rules and concepts

• Time-based rules evaluate conditions such as hours since creation, hours since last public response, hours in Pending, or SLA threshold proximity. They run on a schedule, not at the exact second a threshold is crossed.
• Escalation actions can email a manager, reassign to another group or agent, raise priority, add tags, call a webhook, or close a resolved ticket after a waiting period.
• Escalation levels are usually built as separate rules: first notify the group lead at 50 percent of the SLA, then notify the manager at breach, then reassign if still unresolved.
• Business hours affect time conditions when the rule references a calendar. A rule using 24 business hours can take several calendar days to fire.
• Avoid duplicate escalations by making conditions mutually exclusive and by stopping or narrowing rules after a reassignment.
• Closed and Resolved tickets should usually be excluded unless the rule is specifically designed to reopen or follow up.

Worked example

An Urgent ticket must be answered within 30 minutes. Rule one fires after 30 business minutes with no public reply, emails the group lead, and reassigns to the on-call agent. Rule two fires after 60 business minutes with no public reply and emails the support manager. The second rule excludes tickets already tagged escalated-manager so it does not repeat every schedule cycle. The reasoning: each level needs a distinct condition and a way to prevent repeated firing.

Traps that cost marks

• Expecting immediate escalation; the rule waits for its next scheduled run.
• Using calendar hours when the team works business hours.
• Escalating tickets that are already Resolved or Closed.
• Repeating the same escalation every cycle because no tag or state change stops it.
• Escalating to an inactive agent or an empty group.

Custom Fields

What this domain covers

Custom Fields tests ticket, contact, and company fields: field types, required and visibility settings, portal editing, dependencies, API names, permissions, and the data-hygiene consequences of changing or deleting fields.

Core rules and concepts

• Ticket custom fields support text, multi-line text, dropdown, checkbox, number, date, dependent dropdowns, and cascading selectors where available. Choose the simplest type that supports reporting.
• Each field has settings for agents can edit, customers can edit, required, visible in portal, display name, and an API key. The API key is what integrations use, so renaming the display label should not break the API.
• Dependent and cascading fields let one dropdown control the options in another. They improve data quality but add complexity to forms and reporting.
• Field permissions can restrict who views or edits sensitive fields on higher plans. Do not assume every agent should see every custom field.
• Plans cap the number of custom fields. Check limits before building a form or integration that depends on many fields.
• Changing a field type after data exists can invalidate stored values; deleting a field removes its data from future use and reporting.

Worked example

A team adds an Order ID text field, marks it required on the portal form, visible to customers, and editable by agents. The API key remains order_id while the display label changes from Order ID to Order Reference. Integrations continue to work because they use order_id. If the team later changes the field to a number type, existing alphanumeric order IDs may fail validation. The reasoning: labels are for humans, API keys are for systems, and type changes are data migrations.

Traps that cost marks

• Changing a field type after production data exists without a migration plan.
• Deleting a field that reports and integrations still reference.
• Making a portal field required without checking whether the API can supply it.
• Renaming the API key instead of the display label.
• Creating too many overlapping dropdown fields and calling it reporting.

Forms

What this domain covers

Forms tests how Freshdesk presents different ticket-intake experiences to customers and agents: multiple forms, field selection, conditional rules, required fields, default forms, and routing based on form choice.

Core rules and concepts

• Multiple ticket forms can be offered on higher plans, each with its own fields and layout. A refund request form can differ from a technical support form.
• Form rules can show, hide, require, or make fields optional based on another field’s value. Rules run as the user changes the form, so conflicting rules can make a field impossible to complete.
• The default form is what customers see when no specific form is chosen. If the default form is wrong, most tickets arrive with the wrong fields.
• Fields not on a form can still be set by API, Dispatch’r, or agents; form design does not fully control data entry.
• Form choice can drive routing through Dispatch’r conditions or form-to-group mapping. A form that is not referenced in routing leaves tickets in the default queue.
• Required fields improve data quality but can block API ticket creation if integrations cannot supply them.

Worked example

A refund form asks for Order ID and refund amount. A form rule requires a manager-approval checkbox when the amount is over 100. Dispatch’r routes any ticket from the refund form to the Billing group and sets priority to High. If the approval checkbox is hidden by a conflicting rule, the customer cannot submit the form. The reasoning: form rules, required fields, and routing must be tested together, not separately.

Traps that cost marks

• Leaving the wrong form as default so customers submit incomplete tickets.
• Writing conflicting conditional rules that hide a required field.
• Assuming a field not on the form cannot be set by API or automation.
• Forgetting to route form-specific tickets to the right group.
• Making fields required without checking integration and API payloads.

Ticket Templates and Data Hygiene

What this domain covers

Ticket Templates and Data Hygiene tests how Freshdesk prefills new tickets and how admins keep the account clean: merging duplicates, closing stale tickets, removing spam, deduplicating contacts, and managing retention.

Core rules and concepts

• Ticket templates prefill subject, description, and field values for new tickets; they are not canned responses, which insert reply text into an existing ticket.
• Templates can standardize intake for common requests and reduce missing fields. Placeholders and default values should be tested with real data.
• Data hygiene includes merging duplicate tickets, merging duplicate contacts or companies, closing stale tickets, deleting spam, and archiving unused custom fields.
• Merging tickets moves conversations into a primary ticket and preserves the primary ID. The action is difficult to reverse, so confirm which ticket should survive.
• Closing is not deleting. Closed tickets remain in reports and search; deletion removes them from normal views and can affect audit and reporting.
• Retention policies and trash settings determine how long deleted or closed data remains available. Export or document before bulk cleanup.

Worked example

A customer submits the same issue twice, once by email and once through the portal. The admin merges the portal ticket into the older email ticket so the conversation, requester, and existing SLA stay on one record. The newer ticket is closed as a duplicate and its ID is noted in the surviving ticket. The reasoning: the primary ticket should be the one with the most history and the correct SLA, not simply the newest one.

Traps that cost marks

• Merging the wrong direction and losing the ticket ID customers already have.
• Deleting tickets to clean reports instead of closing them properly.
• Using ticket templates as a substitute for canned responses.
• Bulk-closing stale tickets without checking open customer promises.
• Leaving duplicate contacts so reporting and notifications split across records.

Reports, Analytics and Admin Dashboards

What this domain covers

Reports, Analytics and Admin Dashboards tests how to measure volume, response, resolution, SLA, CSAT, agent and group performance, backlog, and custom analytics. The exam cares about filters, time zones, permissions, and interpreting current versus historical data.

Core rules and concepts

• Prebuilt reports cover ticket volume, first response time, resolution time, SLA performance, agent and group performance, customer satisfaction, and backlog.
• Custom reports and dashboards on higher plans let you choose metrics, dimensions, filters, and date ranges. Save and schedule them for recurring review.
• Report permissions are separate from ticket permissions. An agent may see tickets but not account-wide financial or CSAT reports.
• Time zone and business hours affect date buckets and elapsed-time metrics. A report run in one time zone can disagree with an agent’s local view.
• Current ticket status is not the same as historical state. A report filtered on Open shows tickets that are open now, not tickets that were open last week.
• Data refresh and export behavior vary. Deleted tickets, merged tickets, and changed fields can alter historical counts.

Worked example

An admin builds a report for first response time by group over the last 30 days. The report uses business hours and the account time zone. A group in another region appears slower because its local working hours are offset from the account time zone. The reasoning: the metric is correct for the chosen calendar, but the comparison is misleading unless both groups share a calendar or the report is filtered by local business hours.

Traps that cost marks

• Comparing groups that use different business-hour calendars without noting the difference.
• Filtering on current status and treating it as historical backlog.
• Forgetting that report permissions differ from ticket permissions.
• Assuming deleted or merged tickets disappear cleanly from every historical metric.
• Scheduling exports without checking time zone and date range.

Integrations, Apps, API Keys and Webhooks

What this domain covers

Integrations, Apps, API Keys and Webhooks tests how Freshdesk connects to other systems: marketplace apps, native integrations, custom apps, API authentication, rate limits, webhook actions, retries, and security.

Core rules and concepts

• Native integrations and marketplace apps cover Slack, Teams, Jira, Salesforce, Shopify, Zapier, and similar tools. Each has its own authentication and field mapping.
• API keys are personal. They are typically used as the basic-auth username with any password value. The key inherits the permissions of the agent who created it, so a restricted agent’s key cannot perform admin actions.
• Freshdesk enforces per-account API rate limits. Integrations should handle 429 responses with backoff and should not poll unnecessarily.
• Webhooks are usually triggered from Dispatch’r, Observer, or Supervisor actions. They send an HTTP POST with a JSON payload to an endpoint; retries can duplicate events, so make the receiving endpoint idempotent.
• Custom apps use the Freshworks developer platform and may use OAuth or account-level credentials. Treat app credentials as production secrets.
• Rotate keys when an agent leaves, and use separate keys for separate integrations so one compromise does not affect everything.

Worked example

A Dispatch’r rule sends a webhook to Slack when an Urgent ticket is created. The Slack endpoint receives the JSON payload and posts to the on-call channel. If Slack is temporarily unavailable, Freshdesk may retry, and the channel could receive the same alert twice. The reasoning: webhook delivery is not exactly-once. The Slack workflow should deduplicate by ticket ID and event time.

Traps that cost marks

• Using a departed agent’s API key and losing access when the account is disabled.
• Ignoring rate limits and retry storms.
• Assuming webhooks deliver exactly once.
• Storing API keys in shared scripts or public repositories.
• Mixing sandbox and production credentials.

Security, Audit Logs

What this domain covers

Security and Audit Logs tests account protection and traceability: password policy, two-factor authentication, SSO, IP restrictions, session controls, audit-log coverage, retention, and the difference between audit events and ticket activities.

Core rules and concepts

• Account security settings include password complexity, two-factor authentication, SAML or Google SSO, session timeout, and IP restrictions where available. These controls apply at account level, not per group.
• SSO can bypass local password policy, so the identity provider’s policies become part of your security posture. Deprovisioning in the identity provider must disable Freshdesk access.
• The audit log records administrative changes such as role changes, SLA edits, automation updates, and integration changes, with actor, timestamp, and before/after values where available.
• Audit-log retention depends on plan. Export or archive entries before they roll off if you need them for compliance.
• Ticket activities are not the same as audit logs. A ticket’s conversation and field history show ticket-level changes; the audit log shows account configuration changes.
• Shared admin accounts destroy accountability. Use named admin accounts and review elevated roles regularly.

Worked example

An SLA policy is changed and tickets start breaching. The admin opens the audit log, filters by SLA policy, and finds that a different admin changed the resolution target from 8 to 4 hours the previous evening. The audit entry shows the actor, timestamp, and value change. The reasoning: ticket activities would show SLA breaches on individual tickets, but only the audit log identifies the configuration change and who made it.

Traps that cost marks

• Assuming the audit log keeps entries forever; retention is plan-dependent.
• Looking for configuration changes in ticket activities instead of the audit log.
• Using shared admin credentials and losing actor attribution.
• Enabling SSO without a break-glass admin path.
• Forgetting that identity-provider deprovisioning must actually revoke Freshdesk access.

Sandbox and Data Governance

What this domain covers

Sandbox and Data Governance tests safe change management and data stewardship: testing configuration in a sandbox, refreshing data, promoting or recreating changes, retention, deletion, export, data residency, and auditability.

Core rules and concepts

• A sandbox is a separate Freshdesk environment used to test roles, forms, SLA policies, automations, and integrations before production. It is not a load-testing environment.
• Sandboxes typically do not send real customer emails. Test notifications and webhooks with safe endpoints so you do not contact customers.
• Data refresh copies production data into the sandbox and can overwrite sandbox changes. Export or document sandbox configuration before a refresh.
• Configuration may be promoted where the plan supports it, or recreated manually. Treat promotion as a change with an approval and rollback plan.
• Data governance covers retention, deletion, export, GDPR requests, data residency, and access review. Know where data lives and how long it is kept.
• Audit logs and exports support governance investigations, but they must be retained and protected as sensitive data.

Worked example

An admin plans to change a Supervisor rule that auto-closes Resolved tickets from 48 to 72 hours. In the sandbox, the admin refreshes a copy of production data, changes the rule, and confirms that Resolved tickets remain open longer without triggering duplicate escalations. The change is then applied to production and monitored for one week. The reasoning: the sandbox exposes unintended interactions before customers see them, but refresh timing and email suppression must be controlled.

Traps that cost marks

• Assuming sandbox emails are always suppressed; verify before testing.
• Refreshing sandbox data after making changes and losing the work.
• Using production API keys in the sandbox or sandbox keys in production.
• Treating the sandbox as a performance or load-testing environment.
• Forgetting that data retention and residency obligations still apply to sandbox copies.