Authoring customization points

Global templates ship the same generated code to every organization. Most teams want that: a single, curated, upstream-maintained template they keep receiving improvements to. But some teams need to change one specific piece: a notebook header, a table-options clause, the wrapper around a stored procedure. Customization points let you give them that one piece without handing them the whole template.

A customization point is a named block you create inside a global template. Once a region is wrapped in a named block, organization editors can customize that block (and only that block) while the rest of the template keeps tracking upstream.

Why named blocks

Organization editors cannot customize arbitrary spans of a template. They can only customize the regions an admin has deliberately wrapped in a named block. That restriction is the whole point.

When an organization customizes a named block, the override covers exactly that one section. Everything outside the block still comes from the global template, so the organization keeps receiving upstream improvements to the rest of the file. The override stays small, meaningful, and easy to reason about: it is “this organization changed the notebook header,” not “this organization pinned an opaque copy of the entire template and now drifts from every fix you ship.”

Named blocks keep overrides meaningful and upstream-trackable. Arbitrary-span overrides would not.

The admin workbench

You author customization points in the admin template workbench, the platform-admin surface where you browse and edit global templates.

The workbench shows a template as an ordered stack of cells: block cells (one per named {% block %} section) and glue cells (imports, {% set %} preamble, and raw Jinja interludes between blocks). The cells are the template’s composition index. There is no separate full-file code editor, no Form or Code toggle, no Composition tab, and no Expand control.

The Preview panel renders the whole template live as you edit. It updates whenever you change a cell, so you can confirm the output of any structural change before saving.

How to create a customization point

To create a named block from glue content, use the Convert into block action on a glue cell:

Open a global template from the tree.
Locate the glue cell that contains the region you want to make customizable.
Click Convert into block on that glue cell.
Give the block a clear name when prompted. Names may contain letters, digits, and underscores. The name must be unique within the template; a duplicate is rejected with the conflicting name called out.

The glue cell’s content becomes the default body of the new named block. The block is output-neutral: the template still renders exactly the same code it did before, because an unoverridden block emits its default body unchanged.

At this point the change lives in your current edit. To make it real you have two choices:

Save persists the edited template back to the template file, so the new block ships to every organization as part of the curated baseline.
Hot-patch writes the current cell state to a temporary database override instead of the file. Use it to trial a block without committing it to the repository; the next template deploy overwrites the database row, so a hot-patch is a try-it-now mechanism, not a permanent edit.

Reach for Save when you have settled on a customization point and want it in the baseline. Reach for Hot-patch when you are still experimenting.

Other cell editing actions

With global templates fully editable in the admin workbench, you can do more than just convert glue cells.

Edit a block in place: Click on any block cell to edit its default body. The Preview updates as you type.

Add section: Use Add section to insert a new block cell at the position you choose. Give the new block a unique name.

Delete a block: Use Delete on a block cell to remove it. If organizations have already customized that block, they keep an inert override row in their setup; it does not corrupt their configuration, but it no longer renders. Communicate block removals to affected organizations so they can clean up stale overrides.

Drag to reorder: Drag block cells to reorder them. Order affects rendered output. The Preview shows the result live.

What organization users then see

Once a block is saved, it surfaces to organization users as a customizable block cell in their template workbench view. Organization editors can customize that block, overriding just that section for their organization, while every other cell continues to render from the global default.

A customized block cell shows the organization’s version with a “customized” marker. An untouched block cell shows the shipped default. The organization never has to fork the whole template to change one piece.

Curation philosophy

The temptation is to convert everything. Resist it. The value of a customization point comes from being a deliberate, well-chosen seam, not from blanket coverage.

Convert the few high-value, self-contained pieces (a notebook header, a table-options clause, a procedure wrapper) rather than every glue cell. A good block has two properties:

A complete, runnable default. The block’s default content should generate working code on its own, so an organization that never touches it still gets a sensible result and an organization that customizes it starts from something real.
A single responsibility. The block should cover one coherent concern. A block that bundles three unrelated changes forces an editor to override all three to change one.

Over-wrapping creates noise: dozens of trivial blocks bury the few that matter and make overrides fragile, because a small upstream refactor can disturb many tiny blocks at once. Under-wrapping leaves organizations with nothing to customize and pushes them toward forking the whole template, which is exactly the outcome named blocks exist to prevent. Aim for a handful of meaningful blocks per template.

The bootstrap baseline

You do not have to convert everything from scratch. The common staging call-sites already ship wrapped as named blocks, so organizations have customization points out of the box.

Across the supported target platforms (Databricks, Snowflake, and Microsoft Fabric) the shipped templates already include blocks for:

The notebook parameter cell, which is where the session time zone is set
Table options
Staging initial load, incremental load, and staging-only load logic
The audit columns appended to a generated table
The stored-procedure open and close wrappers

That means an organization can start customizing the most-requested sections immediately, and your authoring work is reserved for the additional, organization-specific points your customers ask for.