SAP Build Work Zone

SAP Build Work Zone separates where content comes from and where users see it:

1. An administrator subscribes to the service in an SAP BTP subaccount and assigns the Launchpad_Admin role collection to the site administrators.
2. In the Channel Manager, content providers are registered. Apps deployed to the HTML5 application repository of the subaccount arrive through a provider that the subscription creates automatically; SAP S/4HANA systems are added as remote content providers.
3. In the Content Manager, administrators combine apps, catalogs, groups and roles, either from providers or created locally.
4. In the Site Directory, administrators create sites and assign roles to them.
5. Each role becomes a role collection in SAP BTP, which is mapped to users or identity-provider groups.

At runtime, the user opens the site, sees the tiles allowed by the user's role collections, and each app runs against its own back end. SAP Build Work Zone is an access and composition layer: it decides what users see, while the apps keep running where they are deployed.

Both editions are consumed as subscriptions on SAP BTP, and both can show federated SAP S/4HANA content. UI integration cards are supported in both editions: declarative cards fully, while some component card features work only in the advanced edition and fail at runtime in the standard edition. Licensing depends on the edition and the contract; the current SAP service description states the metric. For a pure central launchpad, the standard edition of SAP Build Work Zone covers the requirement; the advanced edition is a workplace decision rather than a launchpad decision.

SAP S/4HANA content is not rebuilt in SAP Build Work Zone. It is federated:

1. Expose in the back end. On-premise and in Private Edition, an administrator selects the roles to expose in transaction /UI2/CDM3_EXP_SCOPE (Manage Content for Launchpads on SAP BTP). Recent releases also support derived and composite roles. In Public Edition, exposure runs through a communication arrangement for the communication scenario SAP_COM_0647.
2. Connect on SAP BTP. Destinations point to the SAP S/4HANA system, and a content provider is created in the Channel Manager.
3. Consume. The exposed roles, with their catalogs, tiles and target mappings, appear in the Content Manager and are assigned to a site.

When the back-end content changes, the provider has to be updated before users see the change, either manually in the Channel Manager or through automatic updates that administrators can set up for ABAP-based providers. Content federation keeps SAP S/4HANA as the owner of its launchpad content while SAP Build Work Zone presents it centrally.

• One entry point for several back ends: a single site can combine content from several SAP S/4HANA systems, SAP BTP apps and third-party applications.
• Reuse instead of rebuild: federated roles bring existing catalogs, tiles and target mappings, so the SAP S/4HANA launchpad design is not duplicated.
• Managed service: SAP operates the site runtime, so the central entry point does not depend on a customer-run front-end server release.
• Theming and branding: the license includes the UI theme designer, so sites can follow corporate branding without custom code.
• Room for more than tiles: cards and, in the advanced edition, workspaces let teams build role-based home pages around their apps.

For organizations with more than one back end, SAP Build Work Zone is the SAP-native way to give users a single front door.

• It presents apps; it does not run them. Each app still executes in its own back end, with that system's performance, errors and release cycle.
• Two authorization layers. A user needs the role collection on SAP BTP to see a tile and the back-end authorization, maintained for example in PFCG, to use the app. SAP Build Work Zone does not replace the second layer.
• Federation is a copy with a refresh cycle. The site shows the content state of the last provider update, so back-end changes are not always visible immediately.
• Identity must match. Single sign-on to the back end depends on a consistent user identity across SAP BTP and SAP S/4HANA.
• No process logic. A site can surface tasks and cards, but the sequence of steps across apps and systems is defined elsewhere.

These are boundaries by design: SAP Build Work Zone optimizes access to applications, not the processes that run behind them.

Check the chain from the user to the back end in this order:

1. Is the role collection mapped to the user, directly or through an identity-provider group?
2. Is the role assigned to the site in the Site Directory?
3. Was the content provider updated after the last change in SAP S/4HANA?
4. Is the role included in the back-end exposure?
5. Does the destination to the back end work for this user?
6. Does the user hold the back-end authorization for the app?

If the tile is visible but navigation fails, run /UI2/FLIA in the back end for the same user to analyze the intent. Most SAP Build Work Zone visibility problems are role-mapping or exposure problems, not broken apps.