> For the complete documentation index, see [llms.txt](https://docs.brigge.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brigge.ai/documentation/brigge-for-transformers/pipelines/pipeline-settings.md). # Pipeline settings ## Introduction Pipeline setup has two distinct parts: the logic and the logistics. You use the *canvas* to build the actual structure (the 'when, what, and how' data is synced), and then pipeline settings handle everything else (such as name, queue priority, and error handling). ## Configuring pipeline settings To access pipeline settings, [click the 'cog' icon from the canvas](#user-content-fn-1)[^1]. Settings are opened in the side panel - for example:

Process flow settings - guidance

Option	Summary
Name	The name of this pipeline. This is displayed throughout the Brigge platform.
Description	Optionally, enter a description. For example, you might provide context for anyone reviewing the pipeline for the first time.
Priority	Assign a priority for associated run jobs to be processed: `high`. The run job is processed before anything else. If multiple jobs are queued with this priority, the one queued first takes priority. `medium`. The run job is processed at the earliest opportunity after any `high` priority run jobs are cleared. This is the default setting. `low`. The run job is picked from the queue at the earliest opportunity after any `medium` priority run jobs are cleared. For more information, see Understanding pipeline run queues.
Error handling	Set options to determine what should happen if this pipeline fails. For more information, see Pipeline error handling.

## Understanding pipeline run queues When a pipeline is triggered to run (by a schedule, webhook, or API request), the run is added to a holding queue, known as the *Greenroom*. From here, run jobs are drip-fed to a *Worker* queue and processed. The *Greenroom* queue is checked every minute AND immediately when a pipeline run finishes. This ensures that pipeline runs are continuous. The number of run jobs picked from the *Greenroom* at any one time is determined by the concurrency limit associated with your account ## Pipeline error handling [Error handling options](#user-content-fn-2)[^2] determine the required behaviour if a pipeline run fails:

### Allow manual retries If a pipeline run fails, it can be [retried manually from the history page](/documentation/brigge-for-operators/history-and-retries.md#retrying-a-failed-run-1). By default, this action is allowed, but you can prevent it by setting the `allow manual retries` option to `off`. ### Failure retry schedule The `failure retry schedule` option is used to configure an automated schedule to retry failed runs for this pipeline. {% hint style="danger" %} Use this option with care. Retrying a pipeline run carries the risk of duplicating data that was processed in the failed run. Only set a schedule if you're confident it's safe to process your data multiple times. {% endhint %}


Having chosen to add a schedule, options are displayed for you to set a schedule based on hours or minutes, and also to specify the number of retries to attempt:		For a more granular schedule, you can set the `schedule frequency` to `custom` and define a cron expression.
You can specify one retry schedule. If you need to change an existing schedule, click it. To remove the schedule (so no automatic retries happen), use the 'trash' icon:

### **Failure notifications** Use the `failure notifications option` to determine who should receive an email notification if this pipeline encounters a run failure. Click the associated `+` symbol, then choose an existing notification group, and the environment the pipeline should be running in for a failure to trigger these notifications:

All recipients in the selected notification group will receive an automated alert as soon as a failure is detected in the given environment, enabling faster troubleshooting. {% hint style="info" %} Defining notification groups is an administrative task. For more information, see [Admin menu](/documentation/administrator-menu.md). {% endhint %} [^1]: **How do I get there?**\ Select the 'cog' icon from the canvas: ![](https://2172380191-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8IqdqwZowcxtFpZfLa6k%2Fuploads%2FCqzUMN1Pmd4nk06WQ1HO%2Fpipeline%20settings%20-%20error%20handling%20-%20access%20b.png?alt=media\&token=fc039f92-625e-42f7-a4c0-9166626f6ac5) [^2]: **How do I get there?**\ Select `error handling` from `pipeline settings`: ![](https://2172380191-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8IqdqwZowcxtFpZfLa6k%2Fuploads%2FYMLafmSZ5JJmkhQvvEEC%2Fpipeline%20settings%20-%20error%20handling%20-%20access.png?alt=media\&token=c5690645-77a8-46e2-bd78-318460ec4044)