Create templates in Blueprint Designer¶

Overview ¶

A blueprint version is the template applied to a Govern item. It defines the information collected for the item, how users access that information, and the lifecycle rules that govern the item.

Using the Blueprint Designer, you can define:

Hierarchy to establish parent-child relationships between items.
Fields and actions available for the item.
Views that organize fields, actions, attachments, and containers into reusable layouts.
Item page structure composed of custom and system tabs.
Right panel structure displayed when users select an item.
Workflows and sign-offs that control the item lifecycle.
Hooks that automate operations when items are created, updated, or deleted.

General settings ¶

From Structure, configure the main properties of the blueprint version:

Icon or image: The visual identifier for items that use the blueprint version. By default, it is inherited from the blueprint.
Blueprint version name: The display name of the template.
Blueprint version ID: The unique identifier of the version.
Blueprint version instructions: Optional guidance for administrators who edit the template.
Parent reference: A reference field that identifies the parent item and determines the hierarchy displayed in breadcrumb navigation.
Customizable right panel: Enables a dedicated tab structure for the panel displayed when users select an item.

Define fields and actions, then organize them into views. Associate views with custom tabs or workflow steps to make their content available to users.

Design views ¶

A view is a reusable layout composed of fields, actions, attachments, and containers. Use views as the content of custom tabs and workflow steps.

Reusable components: The same field or action can be included in multiple views.
Containers: Group related fields and actions into sections and nested subsections.
Visibility conditions: Display a field or container only when defined conditions are met.
Table layouts: Configure a view to display content as a card or table when supported.

A field or action is available on an item page only when it is included in a view used by a custom tab or workflow step.

Define fields and actions ¶

Define fields ¶

Fields store the information associated with items that use the blueprint version. Users can view or edit a field when it is included in an applicable view and their permissions allow the operation.

All field types support the following options:

Required enforces a value independently of the views and workflow steps in which the field is displayed.
Is a list allows users to add multiple values to the field.

Note

Users require Read permission to view a field and Write permission to edit it.

Field type	Description	Constraints & Options
	User inputs an integer or decimal value.	Is Required Is a list Define allowed range
	Stores a true or false value displayed as a checkbox.	Is Required Is a list
	User inputs a string value.	Is Required Is a list
	Users choose items from a dropdown list.	Is Required Is a list Define categories
	Users input a date value.	Is Required Is a list
	References another item in Dataiku Govern, such as a governed project.	Is Required Is a list Source type, “Store” or “Compute”, constrain on which allowed blueprints the reference item must be.
	Allows users to upload a file.	Is Required Is a list
	Stores time series data, for example for model metrics charts. This field can be populated only through the Public API or a hook.	Is Required Is a list X and Y labels
	Stores JSON content.	Is Required Is a list

Define actions ¶

Actions allow users to trigger custom Python logic from an item page.

When creating an action, define:

A Name.
A unique ID that cannot be changed after the action is saved.

After saving the action, configure:

Description to explain what the action does.
Python script to implement the action logic.

The script placeholder contains examples for:

Logging and debugging.
Retrieving the user or authentication context that triggered the action.
Retrieving input parameters.
Marking the execution as failed.
Using the Public API.

Create and customize views ¶

Add fields, actions, attachments, and containers to a view. Arrange components by dragging and dropping them, and use nested containers to create subsections.

Configure the following properties from the settings panel:

Properties	Description
Label	Defines the label of a section or field.
Description	Adds a description displayed in a tooltip next to the label.
Documentation	Adds inline documentation written in HTML.
Read only	Display field as read-only and disable editing.
Display field label	Display only the field value, or include both the field label and value.
View type	Displays the content as a card or table.
Visibility conditions	Displays a field or container only when its conditions are met.

Saving a view does not display it automatically. Associate it with a custom tab or workflow step, then save the blueprint version.

Design the item page structure ¶

From Structure, define the tabs available on item pages and in the right panel. Custom tabs display reusable views, while system tabs display content managed by Dataiku.

Artifact page and right panel structures in the Blueprint Designer

Artifact page navigation menu ¶

The Artifact page structure determines the tabs displayed in the navigation menu of items that use the blueprint version. Add, remove, and reorder tabs, and use separators to organize them into groups.

Custom tabs ¶

A custom tab displays the content of a view. For each custom tab, configure:

Tab name: The label displayed to users.
ID: The unique identifier generated from the tab name. The ID will be used in the navigation URL and the ID cannot be changed after the tab is saved.
Icon: The icon displayed with the tab name.
View: The view used as the tab content.

A custom tab can be included in the Artifact page structure, the Right panel structure, or both. When it is used in both structures, its name, icon, ID, and view are shared.

System tabs ¶

System tabs display content managed by Dataiku. The available system tabs are:

Workflow to display workflow steps and sign-offs.
Timeline to display the history of changes to an existing item.
Role assignments to display role assignments to users with the required permissions.

System tabs have a fixed ID and content. They can be added only to the Artifact page structure and appear only when their content is applicable.

Separators ¶

Add separators to divide the navigation into visual groups. Separators can be positioned independently in the Artifact page structure and Right panel structure.

Customizable right panel ¶

The right panel displays information about an item selected from a page. By default, it uses the compatible custom tabs from the Artifact page structure.

Enable Customizable right panel to define a separate Right panel structure. Add or reuse custom tabs, organize them with separators, and set an order that is independent from the Artifact page structure. System tabs are not supported in the right panel.

Design workflows ¶

From Workflow, define the steps that control the lifecycle of items using the blueprint version. Leave the workflow empty for items that do not require a formal process.

Step configuration: Define the sequential stages of the process.
View assignment: Associate a view with each step to control the information available during that stage.
Sign-off requirements: Add approval requirements and assign reviewers.
Visibility conditions: Display a step only when conditions based on the item or workflow are met.

Design sign-offs ¶

Sign-offs add review and approval requirements to workflow steps.

Sign-off workflow ¶

Define how approvals interact with your workflow steps:

Step integration: Add or remove a sign-off from a workflow step.
Approval gate: Require approval before the workflow can advance to the next step.
Visibility logic: A mandatory sign-off is bypassed when its workflow step is not visible as the workflow advances.

Note

Mandatory sign-offs defined on workflow steps having specific visibility conditions can be bypassed if the step was not visible when advancing the workflow. It still applies even if the step becomes visible afterwards. In such case, a warning will be displayed on the workflow step, but the workflow won’t be blocked from going forward, unless that step becomes ongoing again.

Sign-off assignment ¶

Control who is responsible for reviews and approvals:

Feedback groups: Create separate groups for reviews involving multiple stakeholders.
Reviewers: Assign users, groups, or Global API keys. A feedback group can contain multiple reviewers.

Sign-off reset and recurrence ¶

Automate the lifecycle of an approval:

Automated recurrence: Define a schedule that resets an approved sign-off after a specified period.
Manual reset: Reset the sign-off of an individual item when another review is required.

Set rules with hooks ¶

Hooks automate operations during the CREATE, UPDATE, and DELETE phases of an item lifecycle. Each hook is written in Python and configured to run for selected phases.

Hooks can run before or after the action for a selected phase is committed:

Pre-phase hooks run before the item is committed. Use them to validate an operation or populate computed fields.
Post-phase hooks run after the item is committed. Use them for side effects such as sending a notification or synchronizing another system.

New hooks contain sample code demonstrating the available context. For example, use a hook to calculate a risk score from several fields or assign an item owner based on item values.

Warning

An item operation can fail after a pre-phase hook runs. Avoid external side effects and do not use the API client to create, update, or delete other items from a pre-phase hook, because doing so can produce inconsistent results or trigger unsupported nested hooks.

To synchronize related items after the initial operation completes, add their IDs to handler.artifactIdsToUpdate from the pre-phase hook. Dataiku schedules their UPDATE hooks after completing the operation on the initial item.