Integrate SCE workflows with Domino

Overview and goals

The challenge

Statistical Compute Environment (SCE) teams need workflows that enforce regulatory standards, including study code validation, mandatory tagging, digital signatures, and audit trails, without relying on manual processes or bespoke tooling outside the platform. Building these workflows from scratch requires significant development effort, and keeping them in sync with Domino's API as the platform evolves adds an ongoing maintenance burden.

At the same time, SCE teams are increasingly looking to leverage coding assistants to accelerate development, but applying these tools in a regulated environment requires a structured approach that keeps generated code grounded in validated, platform-specific context rather than general-purpose assumptions.

The solution

Domino's application hosting capability, combined with extended identity propagation introduced in Domino 6.2.0, allows SCE administrators to publish custom workflow applications that run inside the platform and act on behalf of the logged-in user.

The Study Publisher app guides users through registering a new study as a Domino project, enforcing governance requirements through the platform's application hosting capability and extended identity propagation. The steps below cover how to teach a coding agent about Domino's API and application model so it can generate a working, compliant app with minimal manual coding.

When should you use a coding agent to build SCE workflows in Domino?

Domino supports expanding the UI's capabilities by hosting applications on the platform that can use the viewing user's credentials to perform custom workflows. This pattern is particularly well-suited when:

• You need to enforce regulatory requirements programmatically. Study code validation, mandatory project tagging, digital signatures, and audit trails are difficult to enforce through UI conventions alone. A hosted app lets you encode these requirements as hard constraints.
• Your workflows are too specific for out-of-the-box tooling. When the compliance logic is specific to your organization's study structure, user authorization model, or metadata schema, a custom app is more maintainable than adapting generic tools.
• You want to reduce manual error in regulated workflows. Automating project creation, naming conventions, and tagging eliminates the class of errors that come from asking users to follow multi-step processes manually.
• You have access to Domino 6.2.0 or later. This blueprint requires the Extended Identity Propagation feature, which allows a system administrator to publish an application that uses the logged-in user's identity to make API calls back to Domino.

In this example, the Study Publisher app will allow signed-in users to:

• List the users current study projects along with the associated study code
• Create new projects associated with existing study codes, with naming and tagging enforced automatically
• Submit a project description and project name
• Record a digital signature as part of the project creation workflow

How to build the Study Publisher with a coding agent?

Step 1. Ground the coding agent in Domino's API and application model

Before writing any application code, provide the coding agent with documentation about the Domino API endpoints. This prevents the agent from making incorrect assumptions about how the API or application hosting model works.

Start by downloading the public API specification for your Domino instance, which is always available at:

https://YOUR_DOMINO_URL/assets/public-api.json

Then provide the agent with the following documentation pages to establish how Domino Apps work, how identity propagation functions, and how Flask apps are structured under the platform's reverse proxy.

Leverage these prompts to load the context:

First, download and understand the domino public API: https://YOUR_DOMINO_URL/assets/public-api.json

Now understand the concept of a Domino App: https://docs.dominodatalab.com/en/latest/user_guide/71635d/publish-apps/

And the method to use a user's identity within an app:
https://docs.dominodatalab.com/en/latest/user_guide/cb9195/app-security-and-identity/#access-identity

Plus how to setup a flask app in domino, in particular how the reverse proxy works:
https://docs.dominodatalab.com/en/latest/user_guide/2039f2/publish-a-flask-app/

And the headers, plus environment variables available to applications:
https://docs.dominodatalab.com/en/latest/user_guide/6a2215/request-headers-and-environment-variables-for-apps/

Step 2. Define the application scope

Once the agent has the platform context, define the application requirements. Start small with the core functionality and iterate from there. The following prompt defines the Study Publisher application:

I want to build a flask app called the "Study Publsher". This app has a number of components:

A study project is any project the user owns or is a collaborator on, which contains the tag "studyCode" with a 6 digit alphanumeric code as value of the format "studyCode:AAA111". Study codes are always included in the project name, with the format studyCode-Name
- studyCodes cannot be reused once a project exists using that code

As input, use a dataset mounted under /domino/datasets/local/studyapp/ , which contains a codes.json file with a mapping for study code to description (of the format {"ABC123": "Phase 2 Clinical Trial - Oncology",})

auth.json contains a mapping of users to study codes, telling the app which users are authorized to access which study codes (format   {"john.doe": ["ABC123", "XYZ789"],})

This app should allow the signed in user to:

- List the user's current study projects, along with study code
- Allow the user to create new projects associated with existing study codes       - Always prefix the name given by the user with the study code
- Add a tag for the new project using the format provided. 
 - When creating projects, prompt the user to enter a description of the project, then present them with a terms of use, and record their digital signature in /domino/datasets/local/studyapp/signatures/
- All endpoints must be assumed to be running in a domino application under the reverse proxy url given by the DOMINO_RUN_HOST_PATH env variable. Do not rely on HTTP_X_SCRIPT_NAME alone

Always sanitise all user input to protect against injection attacks

Step 3. Review and iterate on the generated code

In the first iteration of the Study Publisher, the agent incorrectly resolved the username from request headers rather than from the API. The following prompt corrected this:

Change the username logic to hit the endpoint /v4/users/self , which returns "userName" in the json payload, instead of using the headers

Use /v4//projects/{projectId}/tags to add tags, which takes the input as a list of tagNames: {"tagNames": ["string"]}

Review everything the agent produces after each step before running it. In particular, check that user input is sanitized, that no credentials are hardcoded, that library dependencies are up to date and well-maintained, and that the reverse proxy URL handling is correct.

This kind of targeted correction is a normal part of the workflow. Each iteration should be reviewed before it is deployed.

Step 4. Publish the app with the correct settings

When publishing the Study Publisher in Domino, enable both of the following options:

• Allow App to act for viewers -- this activates Extended Identity Propagation, allowing the app to make API calls using the signed-in user's credentials rather than a service account
• Deep linking -- this exposes the app's endpoints so they can be called by downstream apps or integrations if needed

When publishing this app, make sure to enable the “deep linking” and “Allow App to act for viewers” options

Walking through the Study Publisher in a Domino app

The following screenshots show the Study Publisher running in Domino.

What more can SCE teams build with this approach?

The Study Publisher is a starting point. The same pattern supports more sophisticated SCE workflows:

• External data sources for study metadata and user assignments. Study codes and user authorizations can be read from S3, a database, or an external registry rather than flat files. User assignments can also be synced via SSO: for example, you can forward a list of AD groups associated with studies, and the user token in the application can contain these SSO attributes, which can then be decoded and made available to the app.
• Automated Governance bundle association. Domino Governance bundles can be automatically associated with the study project at creation time, applying customized validation, review, and compliance processes per study without manual setup.
• Centralized project ownership via service accounts. Instead of assigning project ownership to the creating user, a service account token can create the project and add the user as a collaborator, giving platform administrators centralized control over all study projects.
• Automated project seeding. After project creation, a pipeline can be triggered to seed the project with required datasets, configure data source connections, pull in approved code or artifacts, and complete the full setup process automatically.
• Chained apps for complex workflows. The user credentials from the Study Publisher can be passed to a downstream app that acts as a service, enabling multi-step workflows in which each app handles a distinct part of the process.

Contact your Domino PS representatives for help with integrating any of the workflows/features mentioned above.