Skip to main content
A context parameter is a named plain-text value that workflows and agents reference as {{params.<key>}}. Each run resolves every referenced key to the most specific value on its path, so one workflow or agent serves many teams, repositories, and orchestrations without being copied. Definitions live on the workspace Context Parameters page and in each project’s settings; values can be set on projects, repositories, workflows, orchestrations, and agents.

​
When to use a context parameter

Teams copy a workflow, an agent, or an orchestration because one constant differs between the copies: a base branch, a branch-name suffix, a pull request title format, a reviewer list, a set of review conventions. The definition is identical and only the value changes per project, repository, or orchestration. A context parameter keeps one definition and moves the value out of it. Typical keys: base_branch (develop for two legacy repositories, main everywhere else), branch_suffix per orchestration, review_conventions per repository, pr_title_format per project, default_reviewers per project.

​
How values resolve

A parameter has one definition (key, description, optional default) and any number of values, one per entity. When a run is prepared, Overcut looks for each referenced key from the most specific scope to the least specific and uses the first value it finds:
Two placements are deliberate:
  • An orchestration beats the workflow’s own value. The workflow value is what the workflow uses on its own. An orchestration hands configuration to every workflow it runs, so it wins when both exist.
  • A repository sits below a workflow. Repository values describe the codebase, such as its base branch. A workflow author who sets a value on the workflow is making a narrower, deliberate choice.
For example, review_branch has these values: A standalone run of that workflow on that repository uses staging. The same workflow started by the orchestration uses production. Three more rules shape what a run sees:
  • Agent values apply per step, not per run. A value set on an agent applies only to the Agent Run or Agent Session steps that use that agent. Two agents in the same run can resolve the same key differently.
  • Resolution happens once, at preparation. Overcut resolves every referenced key before the first step starts and freezes that snapshot for the run. Editing a default or a value affects the next run, not one that is already prepared.
  • Only referenced keys load, and nothing is broadcast. A run loads the keys its steps and agents actually name. A parameter reaches an agent only through an instruction that contains {{params.<key>}}; it is never added to the agent’s context on its own.

​
Define a parameter

Create workspace definitions from Context Parameters in the workspace navigation. Create project definitions from Project Settings → Context Parameters → Project Context Parameters. Both open the same form.

Choose a key

Enter the Key. Overcut formats it as lowercase with underscores as you type, so Review Branch becomes review_branch. Keys are unique across the workspace, including across the workspace and project levels, and cannot be changed after creation.

Pick the level

Level is either Workspace (visible to every project) or Project: project name. A workspace parameter can be given values at every scope. A project parameter is visible only inside that project, and its default acts as the project’s value, so it takes no separate project value and cannot be given a value on another project’s resources.

Set a default or require a value

The Default value is used when no more specific value applies. Turn on No default: every run must find a value at a more specific level when every run should get its value from a project, repository, workflow, orchestration, or agent. A referenced key with no value stops the run during preparation.
Keys can contain letters, digits, and underscores, start with a letter or underscore, and are at most 64 characters. A value can be up to 16 KB, so multi-line conventions fit. A workflow, including the agents it uses, can reference at most 50 keys.
Values are plain text. They appear in rendered prompts, run logs, and the audit trail. Keep credentials in the Vault.

​
Reference a parameter

Insert a parameter into a supported field with this syntax:
Three editors offer completion: Instructions on an Agent Run step, Instructions on an Agent Session step, and Additional Instructions on an agent. Type {{params. to list the keys visible to the project with their descriptions and defaults. Parameters work with the same template helpers as trigger data. Values are strings, so a switch looks like this:

​
In a Run Script step

The Bash Script body is never rendered, which keeps trigger text and agent output from being interpreted as shell syntax. Put the reference in Environment Variables and read the variable from the script:
Run Script also receives every key the workflow references as OC_PARAM_<KEY>, with the key in uppercase. release_channel is available as $OC_PARAM_RELEASE_CHANNEL. These variables carry the run-wide value, not an agent’s value.

​
Set values per scope

There are two places to manage values:
  • On the definition. Open a parameter and use its Overrides section. Select Add override, choose where it applies (a project, repository, workflow, orchestration, or agent), enter the value, and select Save. The grid lists every value with its type, the entity it belongs to, and the value.
  • On the entity. Open a project (Project Settings → Context Parameters → Project Values), a repository, a workflow (the metadata panel in Workflow Builder), an orchestration (the properties panel with nothing selected), or an agent, and use its Context Parameters panel. Select Add override, pick the parameter, and enter the value.
An entity’s panel lists only the values set on that entity. It does not show what the entity inherits or which value a run would use. To see the effective value and its source, use the Playground preview described below. Values save immediately. A workflow or orchestration value is independent of the draft, so you do not publish to apply it; the next run picks it up. Use Edit to replace a value. Use Delete, then confirm with Remove, to remove it. Runs that include the entity then fall back to the next less specific value or the default. Removing a value never deletes the definition.
Setting a value on a repository requires a workspace-level grant, because repositories belong to the workspace rather than to a project.

​
Preview and verify

​
Before a run

In the Playground, select a workflow and, when relevant, a repository. The Context parameters panel lists each key the workflow references, the value it would resolve to, and the scope that supplies it, for example Repository: web-app or workspace default. The preview uses the committed workflow. If the Playground run is set to use the working draft, the preview follows the draft. A manual run resolves workspace defaults plus project, repository, and workflow values. Orchestration and agent values do not apply, because they are not part of a manual run. The panel is empty when the selected workflow references no parameters.

​
After a run

Open Logs → Workflow Executions, select View Details, then select Context in the run header. The Run Context panel shows read-only JSON with the run’s trigger data, step outputs, and the resolved parameters under params. When an agent used a more specific value, the panel also shows agentParamOverrides, grouped by agent. Run Context shows the frozen values a specific run used. It does not show which scope won. For that, use the Playground.

​
Troubleshooting

​
Lifecycle and governance

Delete a definition. Select Delete on the parameter and confirm the Delete "<key>"? dialog. Every value is removed with it. Published workflows and agents that still reference the key fail at run preparation until you define the key again. Deleting a definition is different from removing one value. Promote to workspace. A project parameter has a Promote to workspace action. The parameter becomes visible to every project, keeps its id and every existing value, and cannot be moved back. Use it when a second project needs the same key, and before a Library template references it. Export and import. A workflow export lists the keys it references, with their descriptions, but not their definitions or values. An imported workflow lands as a draft and publishes only after every referenced key is defined in the target workspace. The same applies to templates installed from the Workspace Library: a template’s keys must be workspace parameters, because a project parameter is not visible to the project that installs the copy. Permissions. Creating, editing, and deleting definitions and setting values are separate permissions on workspace roles. A project parameter follows that project’s role assignments. Workspace parameters, and promoting to the workspace, need a workspace-level grant. Setting a value follows the entity that receives it, so a project editor can set a project or workflow value for a workspace parameter. The UI shows every action; an action you are not allowed to perform fails when you save. Audit Trail. Definition and value changes are recorded in the Audit Trail, including the value itself. Values are never treated as secrets.

​
Chat

Overcut chat can list definitions, create and edit them, set and remove values on any scope, and preview which values a workflow would use on a manual run. It can also insert {{params.<key>}} references into workflow steps and agent instructions, checking that each key exists. Deleting a definition and Promote to workspace stay in the UI. See Chat with Overcut.