Security and Governance

Note: Compose is only available for Beta testing. See Welcome to UKG Compose > Beta Disclosure for more information.

This page explains the security and governance model for UKG Compose at a product level, describing public-facing security expectations for the Pro-first experience.

Security model overview

UKG Compose is accessed through UKG Pro and uses the UKG authentication experience for the Pro-first workflow model.

At a high level, the security model includes:

Authentication through UKG AuthN
role-based access through HCM security rights
controlled access to workflow authoring and administration
product-level controls around event-driven workflow prerequisites
visibility into workflow executions for monitoring and review

For this doc set, the primary supported experience is:

UKG Pro-only
UKG Pro Suite

Note: UKG WFM standalone and FAPS-specific security guidance will be added when that experience becomes available.

Authentication

Users access Compose from within UKG Pro.

For public documentation, the key guidance is:

Tenants must be on the latest supported version of UKG AuthN
Users launch Compose through the standard UKG authentication experience
Users do not need a separate standalone login when entering Compose from an existing UKG Pro session

This keeps the access model consistent with the rest of the Pro-first experience.

Authorization and HCM security rights

Access to Compose should be governed through HCM security rights.

Public documentation should explain:

where Compose access is granted in HCM security
the difference between Viewer Access, Editor Access, and Full Access
which users typically need each level of access
which permissions are appropriate for builders versus reviewers versus admins

A simple role model for documentation purposes is:

Viewer Access
Can open Compose and review workflow-related content that has been made visible to them, with no authoring capability.
Editor Access
Can create and modify workflows within the bounds of their assigned product and security permissions.
Full Access
Can perform broader workflow administration tasks and manage more advanced workflow capabilities.

The final public page should align this section to the actual HCM security configuration and screenshots that are already being collected for Compose access.

Governance of workflow creation

Not every user should have workflow authoring access.

As a governance principle, organizations should decide who can:

Create workflows
Modify production workflows
Activate or deactivate workflows
Review execution results
Approve changes to higher-risk workflows

This is especially important when workflows:

Call external services
Send notifications to broad audiences
React to business events
Contain conditional logic that can affect downstream processing

The documentation should encourage customers to apply workflow authoring rights deliberately rather than broadly.

Event-driven workflow prerequisites

Workflows that start from supported UKG Pro events have an additional prerequisite (see Webhook Triggers and Access and Setup).

If a customer plans to use the HCM Webhooks Trigger node:

The required UKG Webhooks prerequisite must be configured first
The tenant should understand which supported events are available for Compose scenarios
The workflow design should account for the payload and routing logic associated with those events

If a customer is using only:

Scheduled workflows
Manual execution
Form-driven workflows
Direct webhook-driven workflows

then this prerequisite does not apply.

Inbound and outbound workflow boundaries

Compose workflows can interact with other systems and services, so documentation should clearly describe the product-level boundaries.

Inbound workflows

Inbound workflows begin when something external starts the process.

Examples:

A form submission
An inbound webhook
A supported HCM event

For these workflows, builders should understand:

What starts the workflow
What data enters the workflow
What permissions or prerequisites apply
What downstream actions the workflow is allowed to perform

Outbound workflows

Outbound activity happens when a workflow sends information or actions to another destination.

Examples:

Sending a notification
Calling an external API
Updating another service
Creating or updating a ticket in another system

For these workflows, builders should understand:

What data is being sent
Which downstream systems are involved
Whether approvals or exception paths are needed
Who is allowed to configure these actions

Credential and secret handling

The public documentation should include a product-level section on credentials and secrets.

This section should explain, at a minimum:

That workflows may require credentials to call external services
That credentials should be managed through approved product mechanisms
That customers should control who is allowed to configure or use those credentials
That builders should avoid hard-coding sensitive values directly into workflow logic when a supported credential or configuration mechanism is available

Detailed runtime implementation and storage mechanics do not need to be covered in the public guide. Those details belong in more technical or internal documentation.

Data handling considerations

Security reviewers and admins will want to know how to think about data moving through workflows.

Public documentation should describe:

That workflow inputs may contain business data supplied by a trigger or upstream system
That workflows may transform, branch on, and send that data to later steps
That customers should design workflows to use only the data needed for the business purpose
That access to authoring and review features should be limited to appropriate users

The goal here is not to document every implementation detail. It is to set correct product-level expectations around responsible workflow design.

Execution visibility and review

Executions provide visibility into how a workflow ran.

From a governance standpoint, execution history is useful for:

Confirming whether a workflow ran
Reviewing whether a workflow followed the expected path
Checking whether a step succeeded or failed
Troubleshooting errors
Supporting operational review and validation

Documentation should explain that execution visibility is part of the builder and admin experience and that access to those details should align with the organization’s chosen permission model.

Safe workflow design practices

Public documentation should encourage a few standard practices:

Start with a small workflow before expanding it
Test workflows before activating them
Review execution history after each change
Limit authoring rights to the right users
Separate standard paths from exception paths
Be deliberate when workflows send data to other systems
Document prerequisites for event-driven or integration-heavy workflows

These practices help reduce operational risk and make workflows easier to review and support.

Security reviewer checklist

A lightweight reviewer checklist can help security and implementation teams evaluate a planned Compose rollout.

Review questions:

Is the tenant on the latest supported UKG AuthN version?
Are HCM security rights defined for Viewer, Editor, and Full Access users?
Is the HCM Webhooks Trigger prerequisite configured if event-driven workflows are planned?
Are workflow authoring rights restricted to the intended builder population?
Are external integrations understood and approved?
Is there a clear approach for reviewing executions and troubleshooting failures?
Are higher-risk workflows reviewed before being activated in production?

Setup and operations:

Design and implementation:

Nodes and connectors:

Connectors and Connections