Skip to main content

Governed Portal integrations

This guide covers features that require shared Project configuration: signed packages, trusted components, BPMN, Power BI, Qlik and remote targets. Sensitive values are managed by administrators and must never be copied into Portal widgets or files.

Export and import a Portal​

Export creates a signed package of the draft, including files and integrity information. Import verifies the package, shows its origin and contents, and creates a new Portal in the selected Project; it does not overwrite the open Portal.

A package containing trusted code must be signed by a key recognised by the installation. If verification fails or a file has been altered, import stops before creating the Portal.

Component catalogue and trusted code​

To share a custom component, select it and use Submit to catalogue. This creates a signed version in Pending review. A Reviewer other than the author must approve it; it can then be added from the Project catalogue with Import and add.

Sandboxed components remain isolated. A trusted component is accepted only when its version and content match the approved package and the dedicated HTTPS target explicitly allows trusted code. Editing files after import causes a drift error: submit and approve a new version.

BPMN diagram​

The BPMN diagram widget shows a deployed, read-only version. Its selector contains accessible BPMN objects from the Project and the release retains the selected version. A Portal does not grant extra permissions: if a reader loses access to the BPMN object, the widget displays a diagnostic.

Power BI​

Secure URL uses the reader's Microsoft session and may display a sign-in page. App owns data uses a Project binding and a short-lived token generated by Sybot. The Project Owner configures the profile, binding, report and endpoint through Manage profiles and reports, then runs Diagnostics before Preview. Multiple profiles can represent different tenants or identities.

Qlik​

Secure URL retains iframe-based interactive authentication. OAuth impersonation uses qlik-embed and a governed binding:

  1. an administrator makes the Client Secret available in Credential Vault;
  2. the Project Owner creates and diagnoses a profile with tenant, Client ID and identity mapping;
  3. they create a binding with the App ID and choose an app, sheet or chart;
  4. they create and diagnose the Authoring endpoint and the endpoints needed by the targets;
  5. they select the binding in the widget and verify Preview.

The secret is never placed in the Portal. Allowed origins, Qlik permissions, licensing and Section Access must be tested on the published domain.

Local target and remote Agent​

A Local target uses the runtime of the same installation. A Remote Agent target requires an administrator to install and connect a compatible Agent/BFF on the destination. The Owner selects the target type, public address and the available Agent credential.

After Deploy, a remote target may remain Awaiting Agent while the destination verifies and activates the release. The previous version remains active if the Agent is offline or an error occurs. Do not repeat the deploy; wait for reconciliation or provide the diagnostic to the administrator.

Before publishing, diagnose every Power BI and Qlik endpoint used by the release. Configuration changed after the build may require a new release.