Conversation
New page on example automations
📝 WalkthroughWalkthroughA new MDX documentation page is added detailing end-to-end automation patterns and examples, including employee onboarding, offboarding, access cleanup, infrastructure provisioning, and compliance checks, with step-by-step build guidance for each pattern. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@product/admin/automation-examples.mdx`:
- Line 221: The "Wait for Duration" guidance is incorrect because setting the
wait to the longest option (e.g., 7 days) keeps shorter requests alive until the
max; update the docs to recommend instead: read the form's selected duration and
either set the wait dynamically to that value, use branching (evaluate the form
value and route to different flows with 1/3/7-day Wait steps), or create
separate automations per duration, and add a clear note under the "Wait for
Duration" step explaining that step conditions cannot shorten an already-running
wait and therefore do not solve this problem.
- Around line 208-219: The examples assume the Call Function step is named
"provision" but never instruct the reader to name it, causing ctx.provision.*
lookups to fail; fix by adding an explicit instruction to name the Call Function
step "provision" before the Send Slack Message example or, alternatively, update
the Slack template examples to reference a generic step name placeholder (e.g.,
ctx.<stepName>.environment_type and ctx.<stepName>.environment_url) and show
that users must replace <stepName> with the actual Call Function step name they
choose; ensure the doc edits reference the Call Function step and the template
variables ctx.provision.* (or ctx.<stepName>.*) so readers know to match names
exactly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4d137910-b949-4f5e-aba4-2859a5748a25
📒 Files selected for processing (1)
product/admin/automation-examples.mdx
| 4. Add a **Call Function** step. Select your provisioning function. Pass the form inputs as parameters: | ||
| ``` | ||
| environment_type: ctx.trigger.form_fields.environment_type | ||
| requested_by: ctx.trigger.user.email | ||
| ``` | ||
|
|
||
| 5. Add a **Send Slack Message** step. Notify the requester using the function's output: | ||
| ``` | ||
| Your {{ ctx.provision.environment_type }} environment is ready! | ||
| URL: {{ ctx.provision.environment_url }} | ||
| This environment will be automatically deprovisioned in {{ ctx.trigger.form_fields.duration }}. | ||
| ``` |
There was a problem hiding this comment.
Name the Function step before using ctx.provision.*.
These output references only work if the Call Function step is explicitly named provision. As written, readers can follow the setup exactly and still end up with broken template variables in the Slack message.
Suggested doc fix
-4. Add a **Call Function** step. Select your provisioning function. Pass the form inputs as parameters:
+4. Add a **Call Function** step and name it `provision`. Select your provisioning function. Pass the form inputs as parameters:If you don't want to prescribe the step name, change the later examples to use whatever step name the user is told to assign.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 4. Add a **Call Function** step. Select your provisioning function. Pass the form inputs as parameters: | |
| ``` | |
| environment_type: ctx.trigger.form_fields.environment_type | |
| requested_by: ctx.trigger.user.email | |
| ``` | |
| 5. Add a **Send Slack Message** step. Notify the requester using the function's output: | |
| ``` | |
| Your {{ ctx.provision.environment_type }} environment is ready! | |
| URL: {{ ctx.provision.environment_url }} | |
| This environment will be automatically deprovisioned in {{ ctx.trigger.form_fields.duration }}. | |
| ``` | |
| 4. Add a **Call Function** step and name it `provision`. Select your provisioning function. Pass the form inputs as parameters: |
🧰 Tools
🪛 GitHub Check: Mintlify Validation (conductorone) - vale-spellcheck
[warning] 210-210: product/admin/automation-examples.mdx#L210
Did you really mean 'environment_type'?
[warning] 211-211: product/admin/automation-examples.mdx#L211
Did you really mean 'requested_by'?
[warning] 218-218: product/admin/automation-examples.mdx#L218
Did you really mean 'deprovisioned'?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@product/admin/automation-examples.mdx` around lines 208 - 219, The examples
assume the Call Function step is named "provision" but never instruct the reader
to name it, causing ctx.provision.* lookups to fail; fix by adding an explicit
instruction to name the Call Function step "provision" before the Send Slack
Message example or, alternatively, update the Slack template examples to
reference a generic step name placeholder (e.g., ctx.<stepName>.environment_type
and ctx.<stepName>.environment_url) and show that users must replace <stepName>
with the actual Call Function step name they choose; ensure the doc edits
reference the Call Function step and the template variables ctx.provision.* (or
ctx.<stepName>.*) so readers know to match names exactly.
| This environment will be automatically deprovisioned in {{ ctx.trigger.form_fields.duration }}. | ||
| ``` | ||
|
|
||
| 6. Add a **Wait for Duration** step. The duration should match the value from the form. (Note: if the form offers fixed options like 1/3/7 days, you can set the wait duration to match the longest option and use step conditions, or create separate automations per duration.) |
There was a problem hiding this comment.
The longest-wait workaround deprovisions short requests too late.
Step conditions can skip later actions, but they can't shorten a Wait for Duration step that's already set to the maximum. With 1/3/7-day options, this pattern would keep 1-day and 3-day environments alive until day 7.
Suggested doc fix
-6. Add a **Wait for Duration** step. The duration should match the value from the form. (Note: if the form offers fixed options like 1/3/7 days, you can set the wait duration to match the longest option and use step conditions, or create separate automations per duration.)
+6. Add a **Wait for Duration** step. The duration should match the value from the form. If dynamic wait durations aren't supported in your environment, use separate conditional branches (for example, one wait step per duration option) or create separate automations per duration.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 6. Add a **Wait for Duration** step. The duration should match the value from the form. (Note: if the form offers fixed options like 1/3/7 days, you can set the wait duration to match the longest option and use step conditions, or create separate automations per duration.) | |
| 6. Add a **Wait for Duration** step. The duration should match the value from the form. If dynamic wait durations aren't supported in your environment, use separate conditional branches (for example, one wait step per duration option) or create separate automations per duration. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@product/admin/automation-examples.mdx` at line 221, The "Wait for Duration"
guidance is incorrect because setting the wait to the longest option (e.g., 7
days) keeps shorter requests alive until the max; update the docs to recommend
instead: read the form's selected duration and either set the wait dynamically
to that value, use branching (evaluate the form value and route to different
flows with 1/3/7-day Wait steps), or create separate automations per duration,
and add a clear note under the "Wait for Duration" step explaining that step
conditions cannot shorten an already-running wait and therefore do not solve
this problem.
1 participant
New page on example automations
Summary by CodeRabbit