🔓 Alpha Platform Trinity Asset (1.0.18) Release Notes - 26.07.1.0.18

Release Date: 2026-07-22
Version: 26.07.1.0.18
Trinity Asset Version: 1.0.18
Image Vulnerability Scan Report: security-report.pdf (342.8 KB)


[!IMPORTANT]
The inbox optimization does not have to block an upgrade. CASE_FETCH_ALL_PERF_OPTIMIZATION is new in 1.0.18 and enabled by default. If the 1.0.17 Enquiry migration and backfills are incomplete, override features.featureFlags with the full list minus this flag. Upgrade normally, then restore the flag after the backfills finish. Use the same value on alpha-case-service, alpha-jbpm-service, and gts. See Feature-Flag Requirements.


:warning: Breaking Changes

[!CAUTION]
Request-service environment references are now deny-by-default: Existing custom connectors that resolve deployment environment keys must configure REQUEST_ENV_ALLOWED_TARGETS, REQUEST_ENV_ALLOWED_CREDENTIALS, and/or REQUEST_ENV_ALLOWED_VALUES, and external target URLs must match ALLOWED_ORIGINS. See alpha-request-service environment changes.

[!CAUTION]
New local-session paths add database and IDS dependencies: alpha-archival, alpha-request-service, alpha-redirect-service, and alpha-task-distributor now open the shared auth-session store and validate sessions directly with IDS; admin also opens the regular Alpha session store for secondary validation. Ensure database/IDS reachability and complete session settings before rollout. See Local session validation and database reachability.

[!CAUTION]
Service-JWT cutover: Configure internal keys under global.serviceAuth.internal and external public-key keyrings under the exact receiving service. External IDS bearer compatibility is a separate global, temporary opt-in and does not alter internal callers.

[!CAUTION]
IDS client-token compatibility is transitional and disabled by default: Alpha APIs accept IDS client_credentials tokens through Authorization: Bearer only when global.serviceAuth.idsClientToken.enabled is set to true. Machine-to-machine callers should migrate to short-lived RS256 Service JWTs in x-alpha-service-auth; disable the compatibility switch and roll backend receivers after migration.

[!CAUTION]
Removed APIs and legacy enquiry data: Deprecated case-enquiry configuration APIs were removed. Migration 1.0.18 also drops the legacy case-enquiry configuration, fields, and audit tables; rollback recreates empty tables and does not restore their data. Update API consumers and preserve any required legacy enquiry data before upgrading.


:warning: Breaking Changes

[!CAUTION]
Request-service environment references are now deny-by-default: Existing custom connectors that resolve deployment environment keys must configure REQUEST_ENV_ALLOWED_TARGETS, REQUEST_ENV_ALLOWED_CREDENTIALS, and/or REQUEST_ENV_ALLOWED_VALUES, and external target URLs must match ALLOWED_ORIGINS. See alpha-request-service environment changes.

[!CAUTION]
New local-session paths add database and IDS dependencies: alpha-archival, alpha-request-service, alpha-redirect-service, and alpha-task-distributor now open the shared auth-session store and validate sessions directly with IDS; admin also opens the regular Alpha session store for secondary validation. Ensure database/IDS reachability and complete session settings before rollout. See Local session validation and database reachability.

[!CAUTION]
Service-JWT cutover: Configure internal keys under global.serviceAuth.internal and external public-key keyrings under the exact receiving service. External IDS bearer compatibility is a separate global, temporary opt-in and does not alter internal callers.

[!CAUTION]
IDS client-token compatibility is transitional and disabled by default: Alpha APIs accept IDS client_credentials tokens through Authorization: Bearer only when global.serviceAuth.idsClientToken.enabled is set to true. Machine-to-machine callers should migrate to short-lived RS256 Service JWTs in x-alpha-service-auth; disable the compatibility switch and roll backend receivers after migration.

[!CAUTION]
Removed APIs and legacy enquiry data: Deprecated case-enquiry configuration APIs were removed. Migration 1.0.18 also drops the legacy case-enquiry configuration, fields, and audit tables; rollback recreates empty tables and does not restore their data. Update API consumers and preserve any required legacy enquiry data before upgrading.


:sos_button: Support Requests Resolved

  • NPFRBT-1741: Users created through the Admin Service API now retain the requested Active, Enable Task Distribution, and skills settings. Creating a user with isActive: true no longer results in an inactive account.
  • NPFRBT-1625: Standalone deployment values can now omit a service or set it to null without template-rendering failures or ghost resources. The 1.0.18 install/upgrade warning predates the newly added local-session consumers and does not list all of them; use Local session validation and database reachability for the complete override list.
  • NPFRBT-1548: Date Picker fields now display saved values in the configured format and open normally after changing from read-only to editable. Validation no longer fails during that transition.
  • NPFRBT-1707: Fixed Admin task filters so task-name selections and exclusions return only matching task rows instead of unrelated tasks from the same case.

:sparkles: New Features

Service JWT authentication (guide: Integrating External Services with Alpha APIs)

Alpha now supports Service JWT authentication. Alpha services and approved external integrations can authenticate service requests without relying on a user’s login credentials. Operators can grant or revoke an integration’s access independently for each service it calls. Existing user sign-in and session-based access continue to work.

Partial case-data updates

API consumers can now update one top-level case-data field through POST /case/instance/patch-data without sending or replacing the complete case-data object. Simultaneous updates to different fields no longer overwrite unrelated data. Workflow Studio exposes this operation for generated case-service actions.


:wrench: Enhancements

  • Pull-request diffs: Change Tracking skips duplicate relationship work when it opens a pull request, checks merge readiness, and loads the diff.
  • Change Tracking history: Branch history loads one requested page instead of the full history.
  • Change Tracking startup: The UI loads diff viewers only when opened.
  • Change Tracking controls: Tables, menus, dialogs, filters, and copy actions use the current shared UI components.
  • User selectors: User and reviewer lists load with fewer requests in large directories.
  • Inbox read model: Case lists, counts, signals, and dashboards use CASE_FETCH_ALL_PERF_OPTIMIZATION by default. Disable it until the 1.0.17 Enquiry migration and backfills are complete. See Feature-Flag Requirements.
  • Hardened request relay and local session validation: alpha-request-service now reads and validates the signed-in user’s session directly from the shared auth-session store instead of calling alpha-auth-service /auth/validate for each request. Environment-backed relay inputs are now deny-by-default and separated into target, credential, and ordinary-value allow-lists; see alpha-request-service environment changes for required upgrade actions.
  • Live component refresh: Checkbox, Date Picker, Dropdown, Radio Button, Table, Document Viewer, and Renderer components now refresh consistently when supported mapping source changes.
  • Reliable Case Manager startup: Project data is ready before project-dependent screens and downloads run, and simultaneous initialization no longer causes repeated loading.
  • Image coordination: global.imageTag provides one release tag for Alpha services; a service version remains available for explicit pins such as BPM or Marketplace.
  • Per-service image locations: Individual services can override the global registry, repository, or image name for approved mirrors and renamed images.
  • Operational deployment controls: Helm can manage maintenance replicas, including zero replicas when autoscaling is off, and additional Service selector labels for controlled isolation windows.

:bug: Bug Fixes

Helm deployments

  • neutrinos-cm-bpm now uses the Recreate deployment strategy during upgrades, preventing old and new Business Central pods from accessing the shared JGit PVC simultaneously.
  • Fixed rendering failures and unintended resource creation when customer values remove or null a service block. (Needs newer version of Trinity)
  • BPM loads behind a web application firewall with Kong Ingress Controller.
  • Helm no longer fails while preparing service URLs and session settings for deployments with omitted services. The 1.0.18 install/upgrade warning does not enumerate every newly added local-session consumer; the complete list is documented below.

Inbox and filters

  • Unsupported sorts no longer replace a populated inbox with a blank list. The current rows and previous sort indicator are retained, and the UI shows a clear unsupported-sort message.
  • Filterless Enquiry inboxes no longer request every record when a sort header is selected.
  • Date-range filters preserve incomplete selections until both dates are chosen and clear their state reliably.

Case Manager and Studio

  • Fixed duplicate loading placeholders and page-navigation errors in Case Manager.

Change Tracking

  • Branch deep links open the requested branch and commit list.
  • Pull-request diffs, merge checks, and Update Branch now remain accurate for long and merge-heavy histories.
  • Failed merges no longer leave partial configuration changes.
  • Removed the unsupported all-branches selection in Commits view.

Task synchronization

  • An unresolvable task batch no longer prevents later task updates from reaching inboxes.

Security and reliability

  • Invalid or weak service-authentication keys are rejected at startup with clearer configuration errors.
  • External service JWTs cannot choose an Alpha tenant through self-asserted claims. Transitional IDS client tokens use the tenant returned by IDS introspection.
  • Login requests now wait for identity-provider initialization instead of failing during service startup.
  • Updated backend, frontend, object-module, and migration images to address critical and high-severity findings across operating-system, JSON transformation, HTTP/upload/routing, archive, temporary-file, and build/runtime dependencies.

:clipboard: Configuration

Helm values and feature flags

Value Description Required
global.imageTag Shared fallback tag; required only for an enabled service that has no service-specific version. Conditional
services.<category>.<service>.registry / repository / imageName Optional per-service image location overrides. No
services.<category>.<service>.replicas Helm-managed replica override when global autoscaling is disabled; may be 0 for maintenance. No
services.<category>.<service>.service.selectorLabels Additional Service selector labels for normal routing or a controlled isolation window. No
global.serviceAuth.internal.publicKey Public key required when an enabled service verifies internal Service JWTs. Use a Secret reference in production. Conditional
global.serviceAuth.internal.privateKey Private key required when an enabled service signs internal Service JWTs. Use a Secret reference in production. Conditional
global.serviceAuth.internal.keyId Active key version required when an enabled service signs or verifies internal Service JWTs. Conditional
global.serviceAuth.idsClientToken.enabled Default-false global migration switch for inbound IDS client-token introspection. No
services.<category>.<service>.serviceAuth.externalIssuers Public keys for approved external integrations that call this service. No
features.featureFlags Complete feature-flag list when overriding chart defaults. No

Reference internal key material from a Kubernetes Secret rather than placing private keys in values files:

global:
  serviceAuth:
    internal:
      publicKey:
        valueFrom:
          secretKeyRef:
            name: alpha-service-auth
            key: public-key
      privateKey:
        valueFrom:
          secretKeyRef:
            name: alpha-service-auth
            key: private-key
      keyId: v1

Configure a third-party public key only on the service that receives its tokens:

services:
  backends:
    alpha-case-service:
      serviceAuth:
        externalIssuers:
          partner-case-integration:
            partner-case-2026-01: <base64-encoded-public-key>

Third-party tokens require a kid. During rotation, add both keys, move the integration to the new kid, wait through the token lifetime and rollback window, then remove the old key.

IDS client-token compatibility window

External project integrations that are not yet ready for service JWTs can temporarily retain IDS client-credentials bearer authentication:

global:
  serviceAuth:
    idsClientToken:
      enabled: true

This global switch defaults to false and is the only activation control (it cannot be overridden per-service). Enabling it requires compatible alpha-core images, configured features.ids.* credentials, and a rollout of backend receivers. Internal Alpha calls are unchanged and never use IDS bearer fallback. After external teams migrate to service JWTs, set the switch back to false and roll receivers.

Caller mechanics, supported receivers and routes, failure semantics, token-cache/revocation timing, and production checklists are all covered in the companion guide: Integrating External Services with Alpha APIs.

Local session validation and database reachability

In 1.0.18, alpha-archival, alpha-request-service, alpha-redirect-service, and alpha-task-distributor join the existing cookie-capable backends that load the shared PostgreSQL auth session and validate it directly with IDS. Admin also adds secondary regular Alpha session validation alongside its admin session. Each new session path opens a session-store pool and therefore requires auth-session database reachability, the regular Alpha session secret, and IDS connectivity.

The effective runtime settings are:

  • ALPHA_SESSION_NAME and ALPHA_SESSION_SECRET from global.features.session.cm.
  • SESSION_DB_NAME and SESSION_DB_SCHEMA_NAME from services.backends.alpha-auth-service.envs.DB_NAME and AUTH_DB_SCHEMA_NAME; SESSION_DB_SESSION_TABLE and SESSION_DB_PRUNE_SESSION_INTERVAL come from global.features.session.
  • DATA_SOURCE, DB_HOST, DB_PORT, DB_USERNAME, and DB_PASSWORD from the chart’s common database configuration under global.features.database.
  • SESSION_RESAVE, SESSION_ROLLING, SESSION_SAVE_UNINITIALIZED, SESSION_PROXY, and SESSION_COOKIE_* from the 1.0.18 global.features.session configuration and its template defaults.

The chart also renders SESSION_DATA_SOURCE, SESSION_DB_HOST, SESSION_DB_PORT, SESSION_DB_USERNAME, and SESSION_DB_PASSWORD, but the 1.0.18 session runtime reads the common names above. Do not override the SESSION_-prefixed connection aliases expecting them to change session-store connectivity.

If alpha-auth-service is omitted or hosted elsewhere, set SESSION_DB_NAME and SESSION_DB_SCHEMA_NAME explicitly on every enabled local-session consumer. Admin’s secondary regular Alpha session instead requires ALPHA_SESSION_DB_NAME and ALPHA_SESSION_DB_SCHEMA_NAME.

alpha-request-service environment changes

[!CAUTION]
Upgrade action for custom request-service connectors: 1.0.18 no longer allows a relay payload to resolve an arbitrary environment variable. If a payload uses { "type": "environment", "value": { "__alpha_env__": "..." } } with customer- or deployment-specific keys, add every key to the appropriate REQUEST_ENV_ALLOWED_* list. Requests using an unlisted key now fail closed. Target URLs must also match ALLOWED_ORIGINS.

Environment variable Change in 1.0.18 Upgrade action
REQUEST_ENV_ALLOWED_TARGETS New comma-separated allow-list for environment keys resolved as the relay target or client-auth IDS URL. Known Alpha service and built-in IDS/Reels URL keys are already allowed. Add every custom target/IDS URL key used by request payloads. Its resolved external URL must also match ALLOWED_ORIGINS.
REQUEST_ENV_ALLOWED_CREDENTIALS New comma-separated allow-list for environment keys resolved as credentials. IDS_CLIENT_ID, IDS_CLIENT_SECRET, REELS_CLIENT_ID, and REELS_CLIENT_SECRET are built in. Add every custom client ID, client secret, bearer token, username, or password key referenced by a payload.
REQUEST_ENV_ALLOWED_VALUES New comma-separated allow-list for environment keys resolved in ordinary headers, bodies, query parameters, methods, or grant types. There are no built-in generic keys. Add every required custom value key explicitly.
ALLOWED_ORIGINS Now fail-closed for external relay and client-auth destinations, including URLs resolved through custom environment keys. It accepts either a JSON array or a comma-separated list of origins/path prefixes; a path entry permits only that path and its descendants. Include every approved external destination. Internal Alpha destinations configured through built-in service URL keys remain available without adding their origins.
IDS_CLIENT_TOKEN_AUTH_ENABLED New chart-managed switch injected into request-service; it defaults to false. Configure only through global.serviceAuth.idsClientToken.enabled. A per-service env override is rejected by Helm.

alpha-request-service receives the shared local-session settings and connectivity requirements described in Local session validation and database reachability. The environment-reference allow-lists above are additional request-service-specific controls.

Example for a custom connector:

services:
  backends:
    alpha-request-service:
      envs:
        CUSTOMER_CONNECTOR_URL: https://connector.example.com/v1
        CUSTOMER_IDS_URL: https://ids.example.com/oauth/token
        CUSTOMER_CLIENT_ID: <client-id>
        CUSTOMER_CLIENT_SECRET: <secret>
        CUSTOMER_API_KEY: <api-key>
        ALLOWED_ORIGINS: '["https://connector.example.com/v1","https://ids.example.com/oauth/token"]'
        REQUEST_ENV_ALLOWED_TARGETS: CUSTOMER_CONNECTOR_URL,CUSTOMER_IDS_URL
        REQUEST_ENV_ALLOWED_CREDENTIALS: CUSTOMER_CLIENT_ID,CUSTOMER_CLIENT_SECRET
        REQUEST_ENV_ALLOWED_VALUES: CUSTOMER_API_KEY

ALPHA_AUTH_SERVICE_URL remains a valid internal relay target, but request-service no longer uses it to validate UI sessions.

Removed service blocks

Use a standalone environment values file and either delete an unused service entry or set it to null. Review Helm’s install/upgrade notes for generated URLs or session values that depended on the removed service, then set those values explicitly in each consumer’s envs block when the service is hosted elsewhere.

For 1.0.18 specifically, the generated warning omits alpha-archival, alpha-request-service, alpha-redirect-service, alpha-task-distributor, and admin’s secondary regular Alpha session. When alpha-auth-service is removed, apply the explicit session database overrides listed in Local session validation and database reachability; do not rely on the generated warning alone.

Feature-flag requirements

  • CASE_FETCH_ALL_PERF_OPTIMIZATION is new in 1.0.18 and enabled by default. If the 1.0.17 Enquiry migration and backfills are incomplete, override features.featureFlags with the full list minus this key. Restore it after the backfills finish. Use the same value on alpha-case-service, alpha-jbpm-service, and gts.

:counterclockwise_arrows_button: Migrations

Database migrations

Database schema migrations remain automated for Trinity Asset releases. Migration version 1.0.18:

  • Creates side-by-side Change Tracking JSONB snapshot-content and backfill-job tables. Existing row-based snapshot storage remains in place unless the JSONB runtime path is explicitly enabled.
  • Drops the deprecated case_enquiry_config, case_enquiry_fields, and case_enquiry_audit tables. A rollback can recreate their schemas but cannot restore the dropped data.

API migrations

  • Integrations that need partial updates can adopt POST /case/instance/patch-data with { cid, key, value }. Existing full replacement through update-data remains available.
  • Clients of the removed legacy /case/enquiry/* endpoints must move to the current enquiry read-model APIs.
  • Clients of removed tenant-scoped and legacy pull-request Change Tracking endpoints must move to the supported project/branch APIs.
  • Change Tracking history requests are branch-wide; obsolete configType and configId history fields are rejected.

:package: Docker Images

Category Service Name Image Repository Image Version
backends neutrinos-cm-bpm neutrinos.azurecr.io/alpha/neutrinos-cm-bpm 1.0.0
backends alpha-case-service neutrinos.azurecr.io/alpha/alpha-case-service 26.07.1.0.18-8a5ff5d090e5
backends alpha-request-service neutrinos.azurecr.io/alpha/alpha-request-service 26.07.1.0.18-8a5ff5d090e5
backends alpha-delta-service neutrinos.azurecr.io/alpha/alpha-delta-service 26.07.1.0.18-8a5ff5d090e5
backends admin neutrinos.azurecr.io/alpha/admin 26.07.1.0.18-8a5ff5d090e5
backends alpha-auth-service neutrinos.azurecr.io/alpha/alpha-auth-service 26.07.1.0.18-8a5ff5d090e5
backends alpha-config-service neutrinos.azurecr.io/alpha/alpha-config-service 26.07.1.0.18-8a5ff5d090e5
backends alpha-module-service neutrinos.azurecr.io/alpha/alpha-module-service 26.07.1.0.18-8a5ff5d090e5
backends alpha-dashboard-service neutrinos.azurecr.io/alpha/alpha-dashboard-service 26.07.1.0.18-8a5ff5d090e5
backends marketplace-headless neutrinos.azurecr.io/alpha/marketplace-headless 26.06.0.0.27-0922e2b61ea0-security
backends alpha-archival neutrinos.azurecr.io/alpha/alpha-archival 26.07.1.0.18-8a5ff5d090e5
frontends alpha-admin-ui neutrinos.azurecr.io/alpha/alpha-admin-ui 26.07.1.0.18-8a5ff5d090e5
frontends alpha-case-manager-ui neutrinos.azurecr.io/alpha/alpha-case-manager-ui 26.07.1.0.18-8a5ff5d090e5
frontends alpha-workflow-studio neutrinos.azurecr.io/alpha/alpha-workflow-studio 26.07.1.0.18-8a5ff5d090e5
frontends alpha-delta-ui neutrinos.azurecr.io/alpha/alpha-delta-ui 26.07.1.0.18-8a5ff5d090e5
adapters alpha-jbpm-service neutrinos.azurecr.io/alpha/alpha-jbpm-service 26.07.1.0.18-8a5ff5d090e5
cron alpha-task-distributor neutrinos.azurecr.io/alpha/alpha-task-distributor 26.07.1.0.18-8a5ff5d090e5
cron gts neutrinos.azurecr.io/alpha/gts 26.07.1.0.18-8a5ff5d090e5

:telephone_receiver: Support & Resources