Overview

Cross-LifeTime Promotion is an OutSystems 11 LifeTime plugin that promotes an application from an environment managed by one LifeTime (source) to an environment managed by another LifeTime (target), with 4-eyes approval and a full audit log.

It solves a gap in standard LifeTime: a deployment plan can only move apps between environments registered in the same LifeTime. Teams that run separate LifeTimes (for example Dev + UAT in one, Production in another) otherwise have to download and upload packages by hand.

Key features

• Guided 4-step wizard: source environment, application (search, sort, paging), target environment, review.
• Promotes the tagged version running in the source environment; refuses untagged changes, so approvers know exactly what is deployed.
• 4-eyes approval: the requester cannot approve; approvers need Change & Deploy on the target environment.
• Background processing by timer, plus live status checks while a promotion is open.
• LifeTime look and feel: Source → Target header, progress tracker, coloured status badges, deployment log.
• Safety: conflict check before starting, duplicate-request block, feature toggle, secret tokens, Setup check screen.
• Built on the documented LifeTime API v2 cross-infrastructure deployment (binary upload of an .oap).

Prerequisites and compatibility

Both LifeTimes must run LifeTime 11.22.0 or later, the first version with cross-infrastructure deployment through the LifeTime API.

• OutSystems: OutSystems 11 (tested on Platform Server 11.41, LifeTime 11.28.1).
• Install location: the target LifeTime environment (the server that runs the LifeTime console), not an application environment.
• Source service account: created in the source LifeTime (User Management > Service Accounts); needs access to the source environments and permission to download application versions.
• Target service account: created in the target LifeTime; needs Change & Deploy Applications on the target environment(s).
• Target LifeTime setting: Allow direct deployment to Production enabled when the target is a Production environment.
• Network: the target LifeTime server can reach the source LifeTime API over HTTPS.
• Applications: a tagged version in the source environment; no IP-protected modules; dependencies (e.g. OutSystems UI) present in the target at compatible versions.

Service account tokens are shown only once by LifeTime. On LifeTime versions before 11.29 a newly generated token revokes the previous one immediately.

Installation

Install the plugin in the target LifeTime environment's own Service Center; LifeTime cannot deploy to itself.

1. Download CrossLifeTimePromotion.oap from the Forge.
2. Open https://<target-lifetime-host>/ServiceCenter as an administrator.
3. Go to Factory > Solutions (or Applications) > Upload and Publish, and publish the .oap.
4. On publish, the RegisterPluginOnPublish timer registers the plugin in the LifeTime More menu as Cross-LifeTime Promotion.
5. Open the LifeTime console and check that More > Cross-LifeTime Promotion opens the Promotions screen.

If the menu link opens with "Registered role required" (common on OutSystems Cloud), the timer registered the server's internal host name. Open the plugin through the public LifeTime address, go to Setup check > Register plugin in LifeTime menu, then set the site property RegisterOnPublish to False so later publishes keep that link.

The module uses the ServiceCenter user provider, so anyone signed in to LifeTime is signed in to the plugin. Only the LifeTime SDK modules that LifeTime already has are referenced; do not publish a solution pack that contains LifeTime's own modules.

Configuration

All settings are site properties of module CrossLifeTimePromotion (Service Center > Factory > Modules > CrossLifeTimePromotion > Site Properties).

• Source_LifeTimeAPIURL (e.g. https://source-lifetime.company.com/lifetimeapi/rest/v2): source LifeTime API address, no trailing slash.
• Source_ServiceAccountToken (secret): source service account token.
• Target_LifeTimeAPIURL (e.g. https://prod-lifetime.company.com/lifetimeapi/rest/v2): target LifeTime API address, no trailing slash.
• Target_ServiceAccountToken (secret): target service account token (Change & Deploy).
• PromotionEnabled (default True): feature toggle; False stops all processing.
• RegisterOnPublish (default True): re-register the menu entry on every publish.
• PluginVersion (1.0.0): informational, shown on Setup.

Timer schedule. Give the ProcessPromotions timer a schedule (for example every 5 minutes) in Service Center > Factory > Modules > CrossLifeTimePromotion > Timers. Without a schedule, approved requests only move when someone clicks Run Now.

Setup check screen. Open Setup check from the Promotions screen (LifeTime infrastructure permission required). It shows whether each setting is set (tokens are never shown), offers Test source connection and Test target connection, and the Register plugin in LifeTime menu button.

Logging. Keep the LifeTimeAPI integration's Logging Level at Default. Full logging records request headers, which include the service account token.

Using the plugin

A promotion needs two people: one requests it, another approves it; the plugin then deploys it in the background.

Request a promotion

1. Tag the application version in the source LifeTime (application page > Tag Version).
2. Open More > Cross-LifeTime Promotion and click + New promotion.
3. Pick the source environment (all environments of the source LifeTime are listed, e.g. Development or UAT).
4. Pick the application — search by name, 15 per page.
5. Pick the target environment.
6. On Review, check Source → Target, add optional notes and click Create promotion request. If an in-progress request already exists for that app and target, the plugin opens it instead.

Approve or reject

Open the request and click Approve or Reject. The buttons appear only for a user who is not the requester and has Change & Deploy on the target environment.

Track progress

The detail screen shows the Source → Target header, a progress tracker (Requested, Approved, Package, Upload, Deploy, Completed), the current message and the deployment log. While a deployment runs, the page refreshes every 30 seconds and checks the target LifeTime itself; Check status now forces an immediate check.

Needs intervention

If the target reports conflicts or asks for user intervention, review the plan in the target LifeTime, then click Continue deployment or Abort deployment.

How it works

A request moves through fixed statuses; the ProcessPromotions timer does the work, and people only request, approve, continue or abort.

Packaging, upload and the start of the deployment happen in one timer run; each later run (or an open detail page) checks the target until it reports a final result.

1. List environments (source, target): GET /environments/
2. List applications (source): GET /environments/{env}/applications/
3. Find the tagged version and untagged changes (source): GET /environments/{env}/applications/{app}/?IncludeEnvStatus=true
4. Get the version's download link (source): GET /applications/{app}/versions/{version}/content/
5. Download the .oap (source): GET the returned link
6. Create the deployment from the package (target): POST /environments/{env}/deployment (binary body)
7. Check the plan for conflicts (target): GET /deployments/{key}/
8. Start, continue or abort (target): POST /deployments/{key}/{command}/
9. Check status (target): GET /deployments/{key}/status/

Every call goes through OnBeforeRequest, which picks the source or target address and adds that side's service account token.

Security and permissions

Every action is checked on the server against the signed-in LifeTime user; the screens only hide buttons that the server would refuse anyway.

• Open the plugin: any signed-in LifeTime user (ServiceCenter user provider, Registered role).
• Create a request: any signed-in LifeTime user; nothing deploys until approved.
• Approve: not the requester, and Change & Deploy on the target environment (Security_CheckEnvironmentPermission, LifeTime SDK).
• Reject, Continue, Abort: Change & Deploy on the target environment (same SDK check).
• Setup check, register menu: LifeTime infrastructure permission (Security_CheckInfrastructurePermission).

Credentials. Tokens live in secret site properties, are added to calls in OnBeforeRequest as a Bearer header and are never shown on screen. Download links are marked sensitive in the integration logs.

Output encoding. All data shown in the HTML parts of the screens goes through EncodeHtml(). Service Studio still shows its generic reminder on those widgets; it is expected.

Menu web service. PluginConfiguration.ShouldDisplayMenuItemToUser is internal-access only and returns True for every user; the checks above decide what each user can do.

Audit. Every request records requester, approver, dates, the version promoted, the target deployment key and a timestamped log.

Limitations and known behaviours

• One application per request. Promote shared libraries and core modules first, in their own requests.
• Tagged versions only. An application with untagged changes in the source environment is refused with a message; tag it first.
• No LifeTime impact analysis. Binary deployments through the API skip it; the plugin checks the plan for application conflicts before starting and stops at Needs Intervention if any are found.
• Read-only plan in the target LifeTime. Deployment plans created through the API cannot be edited in the LifeTime UI.
• IP-protected modules cannot be moved across infrastructures.
• Production targets require "allow direct deployment to Production" in the target LifeTime.
• Status timing. Final status appears on the next timer run, or within about 30 seconds while someone has the request open. Dates on screen are shown in each viewer's local time (hover shows the time zone); times written inside messages, such as "checked 03:21:05", are server time.
• Development environments. Outside a LifeTime server, the LifeTime SDK checks permissions against its exported sample data, so Approve may not appear; test approvals on the LifeTime server.
• OutSystems Cloud menu link. Registration from the publish timer may store an internal server name; use Setup > Register plugin in LifeTime menu.

Troubleshooting

Start with the request's Deployment log and the Setup check screen; most failures name the setting or step involved.

• "The Source / Target LifeTime is not configured": a URL or token site property is empty. Set the four Source_/Target_ site properties.
• Test connection fails with 401: wrong, expired or rotated token. Generate a new token and update the site property.
• Test connection fails with 404: wrong API URL or trailing slash. Use https://<host>/lifetimeapi/rest/v2.
• "… has changes in the source environment that are not tagged": untagged changes in the source. Tag a version in LifeTime and create a new request.
• "No tagged version … was found": the app was never tagged in that environment. Tag a version in LifeTime.
• Needs Intervention with application conflicts: the target has different versions of shared apps. Review the plan in the target LifeTime; promote dependencies first, or Continue.
• Upload refused, deploy to Production disabled: enable direct deployment to Production in the target LifeTime.
• Failed, protected modules: IP-protected modules are not supported across infrastructures.
• Status stays Approved: the ProcessPromotions timer has no schedule. Set one, or Run Now.
• Approve button missing: you are the requester, lack Change & Deploy on the target, or are testing outside LifeTime. Use another user with the right permission.
• Menu link shows "Registered role required": the link was registered with the internal host name. Use Setup > Register plugin in LifeTime menu and set RegisterOnPublish = False.
• Plugin missing from the More menu: registration failed. Check Service Center errors; run RegisterPluginOnPublish, or use Setup.

Raw API calls are listed in Service Center > Monitoring > Integrations, filtered on module CrossLifeTimePromotion.