Open
Conversation
More details around calling other automations, webhooks, and functions. More details on required inputs/ouputs.
Contributor
📝 WalkthroughWalkthroughThe pull request comprehensively rewrites the automation steps reference documentation, introducing structured guidance on data access, CEL/template syntax, field validation tables, and error handling for each automation step. The changes are documentation-only with no modifications to code signatures or public APIs. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
product/admin/automations-steps-reference.mdx (4)
131-139: Add error behavior documentation.For consistency with other sections, consider adding an "Error behavior" section to document what happens when the target user can't be resolved or when the status change fails.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@product/admin/automations-steps-reference.mdx` around lines 131 - 139, Under the "Modify user status" section add an "Error behavior" paragraph describing failure cases: when the Target user cannot be resolved (e.g., not found or ambiguous) and when the status change API call fails (e.g., validation error, permission denied, or network/error response), include what error is returned, whether the step retries or aborts, and suggested remediation; reference the existing "Modify user status" heading and the "Target user" and "New user status" fields so the error scenarios map back to those inputs.
120-128: Add error behavior documentation.For consistency with other sections, consider adding an "Error behavior" section to document what happens when the target user can't be resolved or when access profile removal fails.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@product/admin/automations-steps-reference.mdx` around lines 120 - 128, Add an "Error behavior" subsection under the "## Remove access profiles" section that documents failure cases and outcomes: describe what happens when the "Target user" can't be resolved (e.g., operation aborted, 404 or "user not found" error returned, no profiles changed) and what happens when removing one or more "Access profiles" fails (e.g., partial failures with details of which profiles failed, retry behavior, and error codes/messages returned). Reference the existing field names "Target user" and "Access profiles" and mirror the tone/format used in other sections so callers know expected error responses and whether the operation is transactional or partial.
148-148: Consider "On-Demand" hyphenation for consistency.The term "On Demand" in "must use an On Demand trigger" could be hyphenated as "On-Demand" when used as a compound adjective. However, verify this matches the exact terminology used in the ConductorOne UI to maintain consistency with the product interface.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@product/admin/automations-steps-reference.mdx` at line 148, Update the phrase "must use an On Demand trigger" in the table row containing "Automation name | Yes | No | The target automation (must use an On Demand trigger)" to use "On-Demand" as a hyphenated compound adjective (i.e., "must use an On-Demand trigger") and confirm the change matches the exact terminology used in the ConductorOne UI before committing.
177-187: Add error behavior documentation.For consistency with other sections, consider adding an "Error behavior" section to document what happens when:
- The target user can't be resolved
- No matching tasks are found
- The specified action fails to complete
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@product/admin/automations-steps-reference.mdx` around lines 177 - 187, Add an "Error behavior" section under the "Perform task action" heading that documents the failure modes for the step: describe what happens when the target user can't be resolved (e.g., step returns a user-not-found error), when no matching tasks are found (e.g., returns a no-tasks-found result or non-fatal warning), and when the specified action fails to complete (e.g., action-specific error with retry guidance). Reference the same step name "Perform task action" and the fields "Whose tasks", "Task type", and "Action to take" so readers can correlate inputs to each error case and include recommended responses or next steps for each error.
🤖 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/automations-steps-reference.mdx`:
- Around line 110-117: Expand the "Modify delegate" section in
product/admin/automations-steps-reference.mdx by adding the missing
configuration fields, error behavior, and examples: list and describe
configurable delegation settings (e.g., delegate_target, permissions/grants,
start_time, end_time, notify_delegate) and indicate which are required and
CEL-validated (reference the existing table format used for other steps), add an
"Error behavior" subsection describing retry/failure states and typical error
messages returned by the Modify delegate step, and include at least two concise
examples showing common use cases (temporary delegation with start/end times and
granting specific permissions). Ensure the new content follows the same style
and heading structure as other automation steps in the doc.
---
Nitpick comments:
In `@product/admin/automations-steps-reference.mdx`:
- Around line 131-139: Under the "Modify user status" section add an "Error
behavior" paragraph describing failure cases: when the Target user cannot be
resolved (e.g., not found or ambiguous) and when the status change API call
fails (e.g., validation error, permission denied, or network/error response),
include what error is returned, whether the step retries or aborts, and
suggested remediation; reference the existing "Modify user status" heading and
the "Target user" and "New user status" fields so the error scenarios map back
to those inputs.
- Around line 120-128: Add an "Error behavior" subsection under the "## Remove
access profiles" section that documents failure cases and outcomes: describe
what happens when the "Target user" can't be resolved (e.g., operation aborted,
404 or "user not found" error returned, no profiles changed) and what happens
when removing one or more "Access profiles" fails (e.g., partial failures with
details of which profiles failed, retry behavior, and error codes/messages
returned). Reference the existing field names "Target user" and "Access
profiles" and mirror the tone/format used in other sections so callers know
expected error responses and whether the operation is transactional or partial.
- Line 148: Update the phrase "must use an On Demand trigger" in the table row
containing "Automation name | Yes | No | The target automation (must use an On
Demand trigger)" to use "On-Demand" as a hyphenated compound adjective (i.e.,
"must use an On-Demand trigger") and confirm the change matches the exact
terminology used in the ConductorOne UI before committing.
- Around line 177-187: Add an "Error behavior" section under the "Perform task
action" heading that documents the failure modes for the step: describe what
happens when the target user can't be resolved (e.g., step returns a
user-not-found error), when no matching tasks are found (e.g., returns a
no-tasks-found result or non-fatal warning), and when the specified action fails
to complete (e.g., action-specific error with retry guidance). Reference the
same step name "Perform task action" and the fields "Whose tasks", "Task type",
and "Action to take" so readers can correlate inputs to each error case and
include recommended responses or next steps for each error.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9e0d3ff3-d30e-4ee4-9598-5fc065d05022
📒 Files selected for processing (1)
product/admin/automations-steps-reference.mdx
Comment on lines
+110
to
117
| ## Modify delegate | ||
|
|
||
| Change a user's status in ConductorOne (e.g., to Active, Disabled, or Inactive). Use this step to maintain accurate user records, such as disabling accounts when employees leave or take extended leave. | ||
| Updates delegation settings for a user. | ||
|
|
||
| **Required fields:** Target user, New user status | ||
| | Field | Required | CEL | Notes | | ||
| |---|---|---|---| | ||
| | Target user | Yes | Yes | The user whose delegation settings will be modified | | ||
|
|
Contributor
There was a problem hiding this comment.
Expand the "Modify delegate" section.
This section appears incomplete compared to the comprehensive documentation provided for other automation steps. It lacks:
- Additional configuration fields beyond "Target user" (what delegation settings can actually be modified?)
- An error behavior section (consistent with all other steps)
- Examples or clarification of what delegation modifications are possible
Users would benefit from knowing what delegation options can be configured and what happens when this step encounters errors.
Would you like me to help draft additional content for this section based on typical delegation use cases?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@product/admin/automations-steps-reference.mdx` around lines 110 - 117, Expand
the "Modify delegate" section in product/admin/automations-steps-reference.mdx
by adding the missing configuration fields, error behavior, and examples: list
and describe configurable delegation settings (e.g., delegate_target,
permissions/grants, start_time, end_time, notify_delegate) and indicate which
are required and CEL-validated (reference the existing table format used for
other steps), add an "Error behavior" subsection describing retry/failure states
and typical error messages returned by the Modify delegate step, and include at
least two concise examples showing common use cases (temporary delegation with
start/end times and granting specific permissions). Ensure the new content
follows the same style and heading structure as other automation steps in the
doc.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
More details around calling other automations, webhooks, and functions. More details on required inputs/ouputs.
Summary by CodeRabbit
Release Notes