Template Requirements Summary
- - Use sticky notes to explain workflow intent, branches, credentials, and expected outputs.
- - Write descriptions in Markdown with useful H2 sections and no raw HTML.
- - Use credential nodes and expressions instead of hardcoded keys or secrets.
- - Build templates around specific use cases like lead routing, support triage, enrichment, or content operations.
- - Check existing templates before submitting and avoid copied workflows.
General Guidelines
What Makes a Successful Template
- Clear purpose: Solve one recognizable business problem and make the expected outcome obvious.
- Production ready: Test with realistic data, document required accounts, and include recovery paths for failures.
- No secrets: Never ship API keys, passwords, bearer tokens, private URLs, customer data, or environment-specific IDs.
- Original work: Submit only original templates or properly licensed open-source work with attribution.
- Balanced specificity: Prefer concrete patterns like "Slack DM for high-priority Zendesk tickets" over generic notification flows.
- Visible logic: Use sticky notes to explain branching, retries, assumptions, and handoff points.
Common Reasons Templates Get Rejected
- Missing credentials documentation or unclear setup sequence.
- Hardcoded tokens, test customer data, webhook URLs, or account IDs.
- Workflow branches that are not labeled or are impossible to validate.
- Thin descriptions that do not explain the business value or required customization.
Documentation Structure
- Overview: Explain what the automation does and who it is for in plain language.
- Prerequisites: List required accounts, scopes, credentials, API access, paid plans, and sample data.
- Setup: Give ordered setup steps that match the imported template or component exactly.
- Customization: Show the fields users are expected to change and explain safe defaults.
- Troubleshooting: Document common failures, rate limits, permission errors, and validation issues.