Can NoClick manage Databricks clusters automatically?

Yes. The Databricks node creates clusters, creates cluster policies, changes a cluster's owner, and reports library install status for a cluster. You can attach these to any trigger, so a schedule, a form submission, or a job event can provision and configure compute without touching the workspace UI.

Can a workflow react to Databricks job runs?

Yes. The node ships triggers for job runs starting, succeeding, and failing, plus an any-job-event trigger and one that fires when a run exceeds a duration threshold. The trigger starts your workflow with the run details, so you can cancel remaining runs, send an alert, or retry the work on a new cluster.

What Unity Catalog objects can it create?

The node creates catalogs, connections, and external locations, and it can check whether a specific table exists before you write to it. That lets a workflow stand up governance objects on demand instead of setting them up by hand for each new dataset.

Can it stop a job or SQL query that is stuck?

Yes. The node cancels a specific job run, cancels all runs at once, cancels a running command, and cancels a SQL statement. Wire it to the duration-threshold trigger or an AI step and a workflow can stop a runaway query or job on its own.

How do I connect Databricks to NoClick?

Add the Databricks node and provide your workspace host along with an access token, which authenticates against the Databricks REST API for that workspace. Once connected, every operation in the node runs against your workspace, including the cluster, job, SQL, and catalog actions.

Databricks Integration

Databricks workspace automation

391 operations availableDatabases & Storage

Databricks is the lakehouse platform where data teams run Spark jobs, query SQL warehouses, and govern data through Unity Catalog. The NoClick Databricks node speaks the Databricks REST API, so a single workflow can spin up clusters, apply cluster policies, cancel running jobs, commands, and SQL statements, create catalogs, connections, and external locations, and check whether a table exists before it writes. It also fires triggers on job run events, so a run starting, succeeding, failing, or overrunning its expected duration can kick off downstream work. Add it to the canvas to turn platform housekeeping and job monitoring into automation instead of manual console clicks.

What you can automate with Databricks

Pick one to start building it.

Databricks Operations

Triggers5

SQL3

SQL Warehouses9

Jobs19

Clusters17

Unity Catalog48

Workspace16

Secrets11

Cluster Policies10

Instance Pools9

Libraries9

Command Execution6

SQL Queries8

Alerts8

Unity Catalog Models12

Unity Catalog Grants11

Unity Catalog Monitoring12

Files17

Pipelines10

Serving Endpoints10

Vector Search14

MLflow Experiments21

MLflow Model Registry24

Feature Store10

Identity19

Access Control21

Apps10

Dashboards13

Genie9

Templates using Databricks

Databricks Job Failure Agent

Files one Linear issue per failed Databricks run with the error copied out exactly, says whether the job has failed once, flakes, or has been broken since Tuesday, and names what downstream just went stale. A failed Databricks run tells you almost nothing on its own, and the question that actually decides your morning is never in the alert: has this job failed before. This agent pulls the run output, reads the last runs of the same job, and writes one Linear issue that says first failure, flaky, or broken since Tuesday, with the error text copied out exactly and the downstream tables you told it about. Whoever picks it up starts from evidence rather than from a red square on a dashboard. ## What people use it for - **First failure or the usual** - Run history is read first, so a job that has quietly failed every night since a schema change is labelled as such, and the one that just broke for the first time is not lost among them. - **The error, character for character** - The exception class and message are copied out of the run output unedited, which is what makes an issue searchable later and what lets the next person match it against a vendor bug report. - **Downstream owners named upfront** - Your runbook notes attach tables, dashboards and owners to each job, so the issue says what is now stale instead of leaving that to be discovered by whoever opens the dashboard at nine. - **One issue per broken job** - Linear is searched for the job and the exception before filing, so an hourly job failing all afternoon leaves one issue and a pattern, not fourteen tickets somebody has to close by hand. ## Before you fork **Does it need permission to run or restart jobs in Databricks?** No. It reads runs, run output and job definitions, and that is the whole of its Databricks access, so a token scoped to read is enough. The writing all happens in Linear and Slack. If you later want automatic retries, that is a separate workflow and a deliberate decision rather than a side effect of triage. **We run hundreds of jobs a night. How often does this actually fire?** Once per failed run, not per run, so cost tracks your failure rate and not your job count. A platform with a few failures a night is a few short runs a night. Jobs you have already accepted as flaky can be marked low stakes in the runbook notes, so they still file an issue without pinging anyone. **What stops it filing the same issue every hour?** Every run begins with a Linear search on the job name and the exception class, and an open match stops it filing. The history check also gives the failure a name, so a persistent break reads as one problem with a date on it rather than as a fresh incident each hour. You can rehearse it against the staged failures before it writes to your real Linear team.

8705 nodes