Notebook Process (Jobs)

A Notebook Process runs a notebook non-interactively as part of a Syntasa workflow. It is one process type among many — alongside Spark code processes, app processes, and so on — and uses the same job orchestration model. Manual runs, scheduled runs, aborting, run history: all of it works the same way as for any other Syntasa process. This article covers what is specific to notebooks; for the rest, see the Syntasa workflow documentation.

Cards and JupyterLab notebooks both work

A notebook process can run a notebook card or a JupyterLab notebook. There is no UX difference — pick whichever notebook makes sense for the work.

What you specify at submission

When you configure a notebook process in a job, three pieces of configuration matter:

  • The notebook — the source notebook to run, picked from your workspace.
  • A runtime template — the kernel and Spark cluster the run will use. See Runtime Attachment in JupyterLab for what a runtime template is and read the warning callout at the end of this article for the important interactive-vs-job distinction.
  • Job parameters — values to pass into the notebook before it runs. Covered next.
Configuring a notebook process in a Syntasa workflow — notebook picker, runtime template, and job parameters.

Syntasa provides a powerful low-code/no-code environment through its intuitive drag-and-drop canvas, enabling users to design and execute complex workflows without extensive programming effort. Users can simply drag, connect, and configure different process nodes to build highly scalable data and AI pipelines visually.

One of the most powerful components within this ecosystem is the Notebook Process. This process allows users to seamlessly integrate and execute notebooks directly within the Syntasa platform while maintaining flexibility, scalability, and operational simplicity.

Unified Notebook Execution Interface

The Notebook Process provides a user-friendly interface where users can:

  • Connect to notebooks available within their environment
  • Attach notebooks to a desired runtime
  • Configure execution settings
  • Schedule notebook runs based on operational requirements

This scheduling capability allows notebooks to function as automated production workflows instead of manual development artifacts, making it easier to operationalize analytics, AI, and data engineering tasks.

Dynamic Input Handling

A major advantage of the Notebook Process is its ability to support dynamic inputs. Users can connect datasets directly into the process pipeline and pass them as input parameters to notebooks during execution.

This enables notebooks to:

  • Consume real-time or pipeline-generated data
  • Operate dynamically across varying datasets
  • Become reusable and parameter-driven components within larger workflows
  • Rather than hardcoding paths or static values, notebooks can intelligently adapt based on upstream process outputs.

Flexible Output Management

The Notebook Process also supports generating multiple outputs from a single notebook execution. These outputs can be stored directly into event stores configured during application creation, enabling seamless downstream integration across the Syntasa ecosystem.


Sequential Notebook Chaining with Magic Commands

Another powerful capability is the support for sequential notebook execution using magic commands. If a notebook executed through the Notebook Process contains magic commands that invoke additional notebooks, Syntasa automatically performs sequential chaining. This means multiple notebooks can be executed in a defined sequence through a single Notebook Process configuration.

This approach provides several advantages:

  • Modular notebook development
  • Reusable notebook components
  • Simplified orchestration
  • Reduced operational complexity
  • Scalable multi-stage execution pipelines
  • Instead of managing multiple independent notebook jobs, users can orchestrate an entire notebook workflow through a single-entry point.

Enabling Operationalized AI and Data Workflows

The Notebook Process transforms notebooks from isolated experimentation tools into production-ready workflow components. By combining scheduling, dynamic parameterization, runtime management, output handling, and sequential execution, Syntasa enables users to operationalize notebook-driven workloads efficiently at scale.

Whether for machine learning pipelines, data transformation, analytics, or AI orchestration, the Notebook Process provides a streamlined and highly flexible interface for managing notebook execution across the platform.

Job parameters and the parameter cell

Job parameters are passed into the notebook using the standard Papermill convention. Tag a cell in your notebook with the tag parameters — that cell holds your defaults. At runtime, Papermill injects an additional cell labeled injected-parameters immediately after your tagged cell, overriding the values you defined. If no cell is tagged, the injected cell goes at the very top of the notebook.

In practice this means: define your parameters once with sensible defaults, and the same notebook can run interactively (defaults take effect) or as a job (the job's overrides take effect). For example, a Python parameter cell:

python
# This cell is tagged "parameters" — see the tip below for how to add the tag.

fixedFromDate = "'2026-03-10'"
fixedToDate = "'2026-03-12'"
dblocation = "s3://my-bucket/syn-cluster-data/eventstores/dev/default_dev"

When a job submits this notebook with overrides, Papermill inserts a second cell right after the one above:

python
# Papermill auto-inserts this cell ("injected-parameters") at run time.
# It overrides the defaults above with the job's values.
fixedFromDate = "'2026-05-10'"
fixedToDate = "'2026-05-11'"
dblocation = "s3://my-bucket/syn-cluster-data/eventstores/prod/default_prod"

Tagging a cell as parameters

In JupyterLab: open the notebook, click the cell, open the Property Inspector (the gear icon on the right edge), find the Cell Tags section, and add a tag named parameters. The tag is stored in the notebook metadata and travels with the file.

A Python cell tagged with `parameters` showing default values that a job can override.

You can configure parameters as placeholders for dynamic values used within a notebook. These parameters are referenced using the @ symbol followed by the variable name.

In Syntasa, there are four types of parameters:

System Parameters

These are automatically provided and include information such as the event store database, execution dates, partitions, output paths, and environment details.

Input Parameters

These define the input connections and data sources required for a notebook process.

Output Parameters

These are used to configure one or more output tables generated by the notebook. Each output can be referenced using its corresponding parameter.

Custom Parameters

These allow users to define their own dynamic values that may vary between executions. Custom parameters are passed at runtime and can be used throughout the notebook.

Notebook Output

When a notebook process completes successfully, the platform produces a Notebook Output artifact: a preview of the executed notebook with all cells run and their outputs captured. Open it from the workflow UI to inspect what the run produced — including charts, dataframes, and printed output — without opening the source notebook.

The Notebook Output artifact for a completed notebook process — preview of the executed notebook with cell outputs captured.

Triggering, scheduling, and aborting

Notebook processes are triggered like any other Syntasa job: a manual Run from the workflow UI, or a configured schedule (cron-style). The schedule itself is configured the same way as for any other Syntasa process; refer to the Syntasa workflow documentation for the full scheduling UI, cron syntax, and timezone behavior.

Aborting a running process is also part of the standard workflow UI; any workspace member can abort. As of 9.1, the abort action correctly targets the kernel pod for the run you intend to stop, even when multiple notebook processes are running concurrently.

Backfills and dynamic parameters

Two common patterns for varying the parameters from run to run:

  • Backfill — manual run with overridden parameters. Trigger a manual Run from the workflow UI and supply explicit values in the Job Parameters field — for example, fixedFromDate="'2026-01-01'" and fixedToDate="'2026-01-31'". The injected parameters cell uses these values for that one run; the schedule continues with its normal values afterwards.
  • Dynamic parameters — computed at run time. Scheduled runs support the same parameter-templating syntax as regular Syntasa jobs — for example, expressing fixedToDate as the run date so each scheduled run gets fresh values without manual intervention. See the Syntasa workflow documentation for the templating syntax available.

Interactive mode — running a process without submitting a job

New in 9.1: any Syntasa process, including a notebook process, can be run in interactive mode. Instead of submitting a full job, attach a runtime to the app and run the process on that runtime directly. This is the fast iteration path — no job-submission roundtrip, no waiting for a scheduler — and it is useful while you are still developing the notebook. When the notebook is ready for production, configure it into a job for scheduled runs.

Interactive runtimes are not job runtimes

The runtime you attach to a notebook in JupyterLab (Runtime Attachment in Notebooks Workspaces is an interactive runtime — it serves your live editing session only. The runtime specified in a notebook process job is a job runtime — it serves scheduled runs only.

These do not share instances, identity, or state. Even if the same notebook has an interactive runtime attached in JupyterLab, a scheduled job against that notebook ignores it and uses the job's configured runtime. Pick and configure them independently.

Related sections