Create Templates in Blueprint Designer¶

Overview ¶

To create a template (technically called Blueprint version) for an item (an artifact), you must design both the visual interface and the lifecycle rules that govern the item.

Using the Blueprint Designer, you can define:

Hierarchy: Establish parent-child relationships between items.
Layout: activate the Overview page and build structured Views.
Governance Logic: Define workflow steps, mandatory sign-offs, and visibility conditions.
Automation: Set rules for the artifact lifecycle.

General Settings ¶

From the General tab in the Main section you have the key information:

Name
ID
Blueprint version instructions: Provide guidance for other administrators interacting with this template.
Field containing parent: Define the parent which is used to define the hierarchy of your govern items for breadcrumbs for users.

To define the content of the Overview page and workflow steps, you will have to build Views, which are the collection of view components, Fields, and Actions, that the users will see and interact with.

Design Views ¶

Views define the content and structure of a Govern item page by organizing Fields, Actions, and Containers, acting as a dynamic display for Overview tab, Workflow steps, and fields.

Modular Components: Containers and subcontainers act as sections to group related fields and actions.
Create Once, Use Everywhere: A single field or action can be included in multiple views. When a shared component is updated, the changes automatically reflect across all views where it is present.
Visibility: For a field or action to be visible on an item page, it must be placed within a view.
Table Layouts: Beyond pages, views also define how rows and data are structured within tables.

Define the view components: Fields and Actions ¶

Define Fields ¶

In this page, you will define which Fields you would like to use on that blueprint version. These will be the fields that Govern users will fill in or view information about the items to which this template has been applied.

Fields can be defined which contain information and can accept user inputs.

Constraints & Options: All field types can be set as:

Required which is a global constraint that is enforced independently of View definitions. If a field is marked as required, it must be populated regardless of which workflow step the item is in. This applies even if the field is only visible on a specific step’s view—the requirement remains active whether that step is unstarted, ongoing, or already completed.
a list allowing users to add multiple values in a single field.

Note

To edit (or view) these fields, users will need to have Write (or Read) permission for that blueprint or field.

Field type	Description	Constraints & Options
	User inputs an integer or decimal value.	Is Required Is a list Define allowed range
	This creates a checkbox in the artifact that a user can select or leave unselected.	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
	Provides other artifacts in Dataiku Govern, for example a specific 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
	Mainly used for models metrics graphs. A field from this type cannot be edited directly from the GUI, only through the public API or in a hook.	Is Required Is a list X and Y labels
	Allow users to put JSON code.	Is Required Is a list

Define Actions ¶

Administrators can create custom buttons to trigger Python-based logic.

When creating a new custom action, the administrator must define:

a Name
a unique ID. All IDs are automatically prefixed with ac.. Once an action is saved, the ID is permanent and cannot be modified.

Upon saving, a dedicated configuration page is created for the action. From there, you can:

Add a Description: Provide context on what the action does.
Define the Python Script: Write the logic that powers the action.

The script placeholder includes helpful hints and code snippets for common tasks, such as:

Debugging: Utilizing logging within the script.
Context: Identifying the user or auth context that triggered the action.
Parameters: Retrieving parameters passed to the script.
Error Handling: Marking a script execution as “Failed” to prevent the action from completing.
Integration: Using the Public API within your logic.

Creating and Customizing Views ¶

Adding Components: You can add individual fields or containers to organize fields. Containers can be nested to create further subsections.
Arranging and Editing: You can easily rearrange view components using a drag-and-drop interface and copy/paste, or add or delete components as needed.
Configurable Properties: The following options can be managed from the right panel menu.

Properties	Description
Label	You can define a label for sections and fields.
Description	You can add a description, which will be displayed in a tooltip next to the label.
Documentation	You can add inline documentation written in HTML.
View type	You can define if you want to display the content as a card or a table.
Conditional views	You can define rules based on another field value to conditionally display a field or a container.

Note

Once these views are created, saved, and published, they will appear in the associated item. Users with appropriate permissions will then be able to read and write information in the fields of those views.

Design the template structure ¶

Design Workflows ¶

The design of the workflow is done is the General tab in the Workflow section.

Step Configuration: Define the sequential stages of the governance process. Leave this section empty for items requiring no formal workflow.
View Assignment: Assign a specific View ID to each step to control what information is displayed at different stages.
Sign-off Requirements: Designate steps that require formal approval. Use the sign-off editor to define specific stakeholders (Users, Groups, or API Keys).
Visibility Conditions: Apply logic to show steps based on Field value, Archived status, Name, Workflow step and/or sign-off.

Design Sign-offs ¶

Dataiku Govern supports extensive customization for complex requirements where predefined templates are insufficient. You can configure sign-off logic to match your organization’s specific approval policies.

Sign-off Workflow ¶

Define how approvals interact with your workflow steps:

Step Integration: Add or remove a sign-off on each workflow step.
Approval Gates: Toggle whether a sign-off approval is mandatory to advance to the next stage.
Visibility Logic: If a step has visibility conditions and is hidden when the workflow advances, mandatory sign-offs are bypassed.

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 multiple distinct groups for multi-stakeholder reviews.
Reviewer Roles: Assign responsibility to specific Users, Groups, or Global API Keys. You can combine multiple roles within a single group.

Sign-off Reset & Recurrence ¶

Automate the lifecycle of an approval:

Automated Recurrence: Setup a schedule to automatically reset an approved sign-off after a specific period.
Manual Reset: Administrators can manually trigger a sign-off reset on individual items when updates are required.

Set rules with Hooks ¶

Hooks are used to automate actions related to artifacts in Dataiku Govern. They are written in Python and will be run during the artifacts lifecycle phases: CREATE, UPDATE, or DELETE. Which phases are selected to run a hook is configurable.

When you first create a hook, sample code will be included to demonstrate the available functionality. Some examples of how hooks can be used include calculating a field based on other fields (for example, if you want to calculate a “risk score” based on inputs in a few different fields), or changing the owner of a project based on some criteria.

Warning

Hooks are executed before the actual action is committed, which means that the item action (save/create/delete) may fail after the hook is run. For this reason, it is not recommended to have external side-effects on other items such as using the API client to save/create/delete an item in Govern because there may be inconsistent results.

In addition, saving/creating/deleting an external item via the API client may also trigger another hook execution which is not supported at the moment and will fail the action.

If there is a need to trigger a hook on a neighbor item for syncing reasons (ie. compute a sum from children items), you may fill the handler.artifactIdsToUpdate list with artifacts IDs to schedule the execution of their UPDATE hooks after the action has completed on the initial artifact.