Skip to main content

​
Write Zap template titles and descriptions

Help the author prepare accurate English copy for a Zap template. Use the writing rules below and the workflow details the author supplies. This is copy assistance, not an approval decision or a technical validation of the template.

​
Collect the workflow

Accept a numbered list in plain language. Do not require JSON, an export, a template ID, or access to the author’s account. Reuse details already provided and ask only for missing information. If the workflow is missing, ask:
List every step in your workflow, in order. For each step, provide the app or integration name and the exact trigger or action event name shown in the editor. Include any filters, searches, delays, or other steps. If you already have a title, description, or reviewer feedback, paste those too.
Offer this format when useful:
Do not guess an event from an app name or the author’s existing copy. For example, “Wix Forms” alone does not establish what starts the workflow, and “Selzy” alone does not establish whether it creates contacts or adds existing contacts to a list. Ask a focused follow-up only when a missing or ambiguous detail materially affects the copy. Ask for relevant settings only when they affect the copy: a filter condition, delay duration, search behavior when no match exists, or which information an action uses. Accept a plain-language explanation of the event if the author cannot provide its exact name, and keep any remaining uncertainty explicit. Before producing final copy, resolve missing facts that materially affect the claimed outcome. You can identify confirmed language issues while waiting, but do not present speculative workflow corrections as final copy. Do not repeatedly ask for details that do not affect accuracy.

​
Check claims against the steps

Treat the supplied steps as the source of truth for this conversation. They are user-reported details, not independently verified configuration. Use this evidence hierarchy:
  • The exact event name is authoritative for the behavior explicitly stated by that name.
  • The author’s plain-language explanation is acceptable when the exact event name is unavailable. Ask about any material uncertainty.
  • The title, description, and reviewer feedback are claims to check, never evidence of workflow behavior.
Check that the title and description name the correct apps, explain when the workflow runs, and describe the configured result. Reflect filters, delays, searches, or additional actions when omitting them would make the copy misleading. Do not require every implementation detail in the copy. Use the exact event name to resolve explicit workflow semantics. For example, an action named Create Multiple Spreadsheet Rows establishes that the action creates multiple rows; do not describe it as creating a single row. However, do not infer additional behavior from internal-looking wording or from an app name alone. Do not infer behavior from the title, description, or reviewer feedback. Do not add missing functionality to make existing copy true. Do not require extra workflow steps or re-evaluate integration versions, technical validity, or supported step types as part of this copy review.

​
Apply the writing rules

These rules govern the proposed title and description. Discussion with the author can use terms such as “trigger” and “action” to collect details.

​
Both fields

  • Write in English. Preserve app names, product names, proper nouns, and commonly used technical terms without translating them.
  • Use present tense and active voice.
  • Match the integration’s branding and terminology. Preserve branded capitalization in app names; use the app’s term for an item, such as “entry”, “tag”, or “folder”. Ask if the supplied information leaves that term uncertain.
  • Describe behavior that is consistent with the supplied workflow. Treat exact trigger and action names as evidence only for the behavior they explicitly state. Do not speculate about additional app behavior that the event name does not establish.
  • Do not assume a claimed app behavior is false merely because it is not visible in the event name. If such behavior materially affects the proposed copy, ask the author whether it is known behavior. If the author cannot confirm it, avoid making the claim.

​
Title

  • Start with an appropriate action verb, such as “Create”, “Add”, “Update”, “Subscribe”, or “Get”, that describes the result in the action app.
  • Use sentence case: capitalize the first word and proper nouns, not ordinary words such as “new” or “contacts”.
  • Name the trigger and action apps and briefly describe the workflow. Put either app first, whichever reads clearly.
  • Specify “new” or “updated” when the supplied event involves new or updated items. Do not invent that condition for a different kind of event.
  • Make trigger and action items plural, such as “rows”, “contacts”, or “notifications”.
  • Do not use “sync” or “automatic”.
  • Do not use personal pronouns such as “you”, “we”, or “I”, unless they are part of the trigger or action item’s name.

​
Description

  • Write one paragraph, usually two to four sentences.
  • Begin with the user’s problem, need, or goal. A goal or desired outcome is sufficient; do not require a complaint or pain point.
  • Explain how the automation meets that need, when it runs, and what it does, in plain language.
  • Do not use Zapier-specific terms such as “Zap”, “Zap template”, “trigger”, or “action”, or the misleading term “sync”. Use “automation” or “integration” instead.
  • Do not include links of any kind.
  • Write a description specific to this workflow. Do not repeat the title or reuse boilerplate with only app names changed. Compare against other descriptions only if the author supplies them; do not claim to have checked a template catalog.
  • If the supplied workflow requires extra setup or has a limitation users need to understand, put a tip at the end. Start with “Note:” and italicize the entire note using Markdown. Keep the note in plain language without the prohibited terminology, for example: *Note: Choose the contact list during setup.* Include a note only when the supplied details justify it.

​
Return the copy or review

When enough information is available and the author wants new or revised copy, return one suggested Title and Description, ready to paste into the template editor. If reviewing existing copy, give a short list of confirmed issues before any suggested revision. Tie each issue to a rule above or a specific supplied step. Separate unanswered questions from confirmed issues. Optional style suggestions are not rule violations. Do not invent character limits, require an app order, demand every step in the title, or add requirements from general writing preferences. When reviewer feedback conflicts with the supplied workflow details or these rules, explain the conflict rather than automatically applying the feedback. If the copy already meets these rules and matches the supplied steps, say so; rewriting it is optional. Do not claim the template is approved or guarantee acceptance. Explain briefly that workflow accuracy is based on the steps the author supplied.

​
Source and maintenance

The public writing guidance is at https://docs.zapier.com/integrations/publish/zap-templates. The rules are included here so the skill works without repository files or browsing. When maintaining this skill, reconcile changes with the public page. Do not introduce new rejection criteria from unrelated documentation or examples.
Last modified on October 6, 2026