Use a Script step when a routine needs a repeatable rule: check a result, reshape data, calculate a value, or prepare information for the next step. Scripts are saved separately and can be reused across routines.
Cedros routine scripts use Rhai, a scripting language, and run on the server inside a restricted sandbox. If you do not write Rhai, ask a developer to prepare and review the script. You can still manage where a reviewed script is used and check its results.
Decide whether a script fits the job
A script is useful when you can describe a consistent transformation or check. For example, it might verify that a summary has required fields, select the relevant values from a data result, or return a clearly structured report.
Use Data call steps to obtain supported data and Job steps for the operations those jobs provide. A script works with the input and context passed to it; it does not independently browse a website, call an external API, read local files, or run a shell command.
The sandbox also restricts module imports, dynamic evaluation, execution time, and resource use. Keep scripts focused on the data the routine needs rather than treating them as a general-purpose application server.
A script does not call an AI model simply because it is a script. Other steps in the same routine may use AI. Review the whole workflow and its AI usage and costs before testing it.
The sandbox does not make the entire routine a preview. Some scripts return information that requests a supported routine action, and later steps can perform real work. Check what the script returns and how the routine uses that output before running it.
Find or create a saved script
Open Routines → Manage scripts. Use Search to find a script by its title, ID, or description, then open it to review its purpose and code.
The library includes built-in scripts, such as Format analytics report. Read the description and code before choosing one; a title alone does not establish that its expected input matches your routine or that it has no downstream effects.
To create a script:
- Select New script.
- Enter a clear Title that describes its job.
- Use Description to explain the input it expects, what it returns, and any important limits. The description helps people choose the right script later.
- Enter the reviewed Rhai code.
- Select Add, read any validation error, and confirm that the script appears in the library after saving.
When editing an existing script, the save button is Save. Its Script ID is read-only because routine steps use that ID to refer to it. Changing the title does not create a separate script or isolate the change from existing routines.
Cancel or Back to scripts leaves the editor. If there are unsaved changes, review the prompt before discarding them. If saving fails, keep the error and your intended changes available while you correct the problem.
Creating or editing scripts requires the appropriate feature access. A saved script is available for selection; saving it does not add it to a routine or start a run.
Agree on the input and output
A script must define fn run(previous_step_output, context) and return a value that Cedros can represent as JSON. Your developer should check three parts of that agreement:
- Input: the value arriving from the preceding step or the selected branch source. Identify whether it is text, an object, a list, or another supported value, and which fields are required.
- Context: the routine information supplied for the run, including identifiers, timing, configured input, and available runtime context. Do not assume every optional source is present.
- Output: the value the next step or final routine action expects. Define its fields and what should happen when input is empty, incomplete, or unsuitable.
For example, if a script formats a summary, specify whether the previous job returns plain text or structured data. A script written for a structured object may fail when it receives text, even if the text looks like a useful summary to a person.
Agree on how missing information is handled. A check should report a useful failure or a clearly defined result; it should not silently invent a value that later work treats as verified.
Return only what the next part of the workflow needs. Script output may appear in run details or be passed into an action or notification. Avoid copying the entire context into a result when a few fields are sufficient, and do not put credentials in script code or output.
Saving validates the Rhai source and the required function. It does not prove that the script works with every input, produces the intended business result, or is appropriate for a particular routine.
Add the script to a routine
Open the routine that should use the script. If it is already on, turn it off before making changes you want to review before scheduled execution. See Pausing or changing a routine for the difference between stopping future scheduled work and work already requested.
For a built-in routine, choose Edit steps. For a routine you created, the step editor is already shown. Use Add step, choose Script as the step type, and select the intended saved script in the Script field.
Place the step after the operation that supplies its input. Review any later job, branch, or final action that consumes its output. A suitable script in the wrong position can still receive the wrong data.
You can also choose Add script… from the script picker. In the New script dialog, complete Title, Description, and Rhai code, then select Save script. After it saves, the new script is selected for the step.
Select Save changes on the routine to keep the step selection and its position. Save script saves the reusable script; Save changes saves how the routine uses it. If you discard the routine edits afterward, the separately saved script remains in the library.
For the rest of the setup, see Creating a recurring routine. Check the saved steps, schedule, delivery, and current on/off state before proceeding.
Test the whole path deliberately
Ask the script's developer to check a representative input and meaningful edge cases, including empty or missing values, an unexpected input shape, and a result that should fail validation. Use non-sensitive examples with known expected outputs.
For a routine-level test, review all of its steps and destinations before selecting Run now. It executes the saved routine and can create content, change data, or send notifications through the workflow. It is not an isolated script preview.
Select Run now once when those effects are intended, then inspect Run history → Show details. Check the Script step's outcome, the result received by later steps, and the final output destination. See Testing and troubleshooting a routine for reading run outcomes and avoiding duplicate work.
Use the reported problem to choose a correction:
- Source does not parse or the required function is missing: correct the Rhai code and function signature before saving again.
- Script not found or no script selected: inspect the step's selection and choose an existing script with the intended behavior.
- Runtime error or unexpected output: compare the actual input with the expected input and review the failing operation or returned fields.
- Time, operation, or memory limit: simplify or bound the work rather than repeatedly running the same oversized operation.
- Execution capacity is busy: check the run outcome before retrying; avoid creating repeated manual requests while waiting.
A successful run means the workflow completed, not that its content or calculations are correct. Compare the output with your expected result, including any action or notification produced. Check what already completed before requesting another run after a failure.
Change a shared script carefully
Before editing a saved script, identify the routines that select it. The script is a shared resource: saving new code changes what those routines can use. Saving the script does not turn them off or create a separately approved version for each routine.
For a change that needs review, pause the affected routines first and check for work already in progress or queued. Do not assume a queued routine request preserves a private copy of every script's code. Keep a copy of the previous source if you may need to restore it.
If you want to try a different approach in just one routine, create a separate script with a clear title and select it only in that routine. This lets you review the new behavior without replacing a script used elsewhere.
After saving, test the affected input/output paths, review the results, and resume the intended routines. Remember that changing a reusable script and saving a routine are separate operations.
To remove a custom script, open it and use Script actions → Delete script. Deletion is permanent, and Cedros blocks it while saved routine steps still reference the script. Remove or replace those references and save the affected routines first. Turning a routine off alone does not remove its reference.
Built-in scripts cannot be deleted. Treat edits to a built-in script with the same shared-use care as any other script; creating a separate script is often clearer when you need behavior for one particular workflow.