Zoho: Update Workflow Rule Execution Order for Module
Zoho workflowRules.reorderWorkflowRules: arguments, response, policy and SDK examples.
← Workflow rules operations · Get started
Operation zoho.reorderworkflowrules
Provider route: PUT /crm/v8/settings/automation/workflow_rules/actions/reorder. Alter supplies the connection’s credentials and routing.
Call through Alter
Section titled “Call through Alter”Install @alter-ai/sdk @alter-ai/zoho with npm, or alter-sdk-zoho with pip. Supply your connected customer’s grant ID and the arguments described below.
import { App } from "@alter-ai/sdk";import { ZohoIntegration } from "@alter-ai/zoho";
async function execute(input: Parameters<ZohoIntegration["workflowRules"]["reorderWorkflowRules"]>[0]) { const app = new App({ apiKey: process.env.ALTER_API_KEY! }); try { const provider = new ZohoIntegration(app, { grantId: process.env.PROVIDER_GRANT_ID! }); const call = await provider.workflowRules.reorderWorkflowRules(input); const result = await call.wait(); return result.bodyJson(); } finally { await app.close(); }}import osfrom alter_sdk import Appfrom alter_sdk_zoho import ZohoIntegration
async def execute(arguments): async with App(api_key=os.environ["ALTER_API_KEY"]) as app: provider = ZohoIntegration(app, {"grant_id": os.environ["PROVIDER_GRANT_ID"]}) call = await provider.workflow_rules.reorder_workflow_rules(arguments) result = await call.wait() return result.body_json()| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | object | Root | Additional keys: not allowed |
query | object | Optional | Additional keys: not allowed |
query.module | string | Optional | Format: string |
body | Model | Optional | Expand Update Workflow Rule Execution Order for Module — request body — body |
Referenced models: Update Workflow Rule Execution Order for Module — request body — body
Response
Section titled “Response”Response media type: application/json. The table describes the pinned successful response. Referenced models link to their complete fields.
| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | Model | Root | Expand Update Workflow Rule Execution Order for Module — response body |
Referenced models: Update Workflow Rule Execution Order for Module — response body
Schemas
Section titled “Schemas”Update Workflow Rule Execution Order for Module — response body
| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | object | Root | Represents the success response returned after reordering workflow rules. Additional keys: not allowed |
reorder | array | Optional | Represents the array of workflow rule objects with their updated execution order. Maximum items: 125 |
reorder[] | Model | Each item | Expand Update Workflow Rule Execution Order for Module — response body — reorder item |
Referenced models: Update Workflow Rule Execution Order for Module — response body — reorder item
Update Workflow Rule Execution Order for Module — request body — body
| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | object | Root | Represents the request body for reordering workflow rules, containing the new position assignments for each rule. Additional keys: not allowed |
reorder | object | Required within parent | Represents the reorder payload containing the list of workflow rules and their updated execution order. Additional keys: not allowed |
reorder.workflow_rules | array | Optional | Represents the array of workflow rule objects for which you want to update the execution order. Maximum items: 10 |
reorder.workflow_rules[] | object | Each item | Represents a single workflow rule entry in the reorder request, specifying the rule ID and its new module-specific sequence number. Additional keys: not allowed |
reorder.workflow_rules[].id | string | Required within parent | Specify the ID of the workflow rule for which you want to update the execution order. Maximum length: 20 |
reorder.workflow_rules[].module_specific_sequence | integer | Required within parent | Specify the new execution order for this workflow rule within the module. The index must start from one. Format: int32 |
Update Workflow Rule Execution Order for Module — response body — reorder item
| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | object | Root | Represents a single item in a multi-status response array, including a response code, status indicator, message, and optionally the resource details. Additional keys: not allowed |
code | string | Optional | Represents the API response code indicating the operation result, such as **SUCCESS** or **INVALID_DATA**. Maximum length: 255 |
details | Model | Optional | Expand Update Workflow Rule Execution Order for Module — response body — reorder item details |
message | string | Optional | Represents the message describing the operation result or error. Known values: workflow created, workflow updated, workflow deleted, WorkFlow Rule deleted successfully, rules reordered successfully, Workflow cloned successfully |
status | string | Optional | Represents the response status indicator, such as **success** or **error**. Maximum length: 7 |
Referenced models: Update Workflow Rule Execution Order for Module — response body — reorder item details
Update Workflow Rule Execution Order for Module — response body — reorder item details
| Field | Type | Presence | Description and constraints |
|---|---|---|---|
$ | object | Root | Represents the details object within a success response, containing the unique ID of the created or updated resource. Additional keys: not allowed |
id | string | Optional | Represents the unique ID of the SuccessResponseDetails within the workflow rule. Maximum length: 255 |
Policy, approvals and errors
Section titled “Policy, approvals and errors”SDK function policy ID: zoho.reorderworkflowrules. Catalog operation: reorderWorkflowRules. Rules can name either ID; function rules distinguish managed calls and conservatively cover raw calls sharing the route. Existing grant permissions and policy rules apply. wait() returns an immediate result or waits for a required approval; it never approves the request itself. Persist the approval ID to resume after a restart.
Provider errors retain their response; JSON decoding raises ProviderAPIError for provider failures. ManagedOperationError identifies contract/input/retention errors. See error handling and provider-specific behavior. Sensitive input may be refused before approval storage. A decoding error never resubmits a write.