Saved Bulk Actions documentation

Documentation for Saved Bulk Actions. This describes the application as it exists today; it will be extended as the application changes.

Requirements

  • A Freshdesk account and the ability to install a Marketplace or custom application in it.
  • A Freshdesk API key belonging to an agent whose permissions allow updating the tickets you intend to change.
  • The fields you intend to write must be writable through the Freshdesk API in your account.

Configuration

The application asks for two installation parameters: your Freshdesk subdomain and a Freshdesk API key. The subdomain is validated as a subdomain only — not a full URL. The API key is stored as a Freshworks secure installation parameter, which means it is attached to outbound request headers by the platform and is never exposed to the browser.

How a run works

  • Choose a filter and a date range. The application enumerates every matching ticket, splitting the range as needed.
  • Preview the match count, then dry-run the change to see current and proposed values without writing.
  • Confirm the run. Updates are submitted in bounded batches with rate-limit aware pacing.
  • Each submitted batch is verified per ticket against its Freshdesk job record.
  • Export the audit CSV of old values, new values, outcomes and timestamps.

Limits you should know

  • Freshdesk applies an account-level API rate limit. A large run consumes it, and the application paces itself against the limit your account reports.
  • A range that cannot be split into a window under the search cap is reported explicitly rather than truncated.
  • The application writes only the fields you select, and only after an explicit confirmation.

Troubleshooting

  • Authentication failures are almost always a wrong subdomain or an API key belonging to an agent without update permission.
  • If a field cannot be written, check that it is writable through the Freshdesk API and that the value matches one of the field's choices.
  • If a long run stops early, resume it — run state is stored per shard and resumes from its recorded position.