Publishing and Portal Access

The Publishing panel collects releases, publishing status, and Portal permissions. The operations shown depend on individual permissions, the role in the Project, and the features enabled by the platform administrator.

Prepare a release

Before publishing:

1. save all changes;
2. run Validate and fix errors;
3. test the draft with Preview;
4. select Publish to open the panel;
5. create a New build release.

A release is an immutable copy of the verified revision. Subsequently modifying the draft does not change already created releases.

Understand and manage artifacts

Every successful build produces an artifact: the executable HTML document of the Portal, complete with layout, compiled styles, and widget runtime. The document is associated with a manifest listing source revision, size, capability, and used dependencies.

The hexadecimal value shown after the build is the SHA-256 hash of the content. It is not a password nor a code to be entered elsewhere: it uniquely identifies the artifact and allows Sybot to verify its integrity.

In the Publishing → Builds and artifacts panel you can:

• view preview builds and releases with status and revision;
• open Details to read the full hash, size, manifest, and diagnostics;
• use Open artifact to inspect the generated document;
• cancel a build still in queue or running.

Successful artifacts are not manually deleted by the editor: a release may depend exactly on that immutable content. Ordinary management occurs via approval, deployment, revocation, and rollback of releases.

A Publisher or Owner can approve a successful release. Approval does not modify the draft and makes the release selectable for publishing to destinations already made available. The status is updated without reloading the page.

If no destination is available, contact the Project owner or the platform administrator. Do not attempt to reuse a destination belonging to another Project.

Publish to the first target

1. approve the created release;
2. as both Portal and Project Owner, create the target with the exact origin, for example https://portals.example.com, without a path;
3. if the release contains Power BI App owns data, open Manage profiles and reports, create an endpoint for the target or its environment fallback, and run Diagnostics until it is verified;
4. select the approved release and the target, then start Deploy;
5. wait for the active state and use Open to test the Portal.

Production and staging require HTTPS. HTTP is available only for a development target on localhost. If a build succeeds but the panel does not refresh, use Refresh and inspect the list before creating another release.

If the release uses Qlik OAuth impersonation, its profile and endpoint must also have a successful diagnostic. For a Remote Agent target, the administrator must have prepared the destination: after deploy, the state remains Awaiting Agent until the release is verified and activated. The previous version remains available. See Governed integrations.

What to expect from a Remote Agent target

When you use Open, the remote runtime may redirect you to the sign-in page of the Sybot installation that owns the Portal. After authentication, the browser automatically returns to the Portal; no second editor configuration is required.

Layout, styles, and static content come from the release activated on the target. Widgets that use data, User Views, Workflows, BPMN, Power BI, or Qlik continue to apply the permissions and configuration of the owning Sybot installation in real time. They may therefore be temporarily unavailable when the platform cannot be reached, even if the static part of the Portal is already visible.

Verify publishing

During activation the panel shows the current status. When the operation is complete, Open appears, allowing you to test the Portal with the same access controls applied to end users.

For a remote target, Last Agent contact confirms that the Agent has communicated with Sybot. It does not replace testing dynamic widgets.

During acceptance testing, compare widget position, width, and height with the Preview of the same revision. Geometry is part of the immutable artifact: after an update that changes Portal rendering, create a new build and release; deploying the same release again does not rebuild it.

An unsuccessful publishing does not replace the already active version. Read the message shown, fix the indicated cause, and repeat the operation with a valid release.

When a previous version is available, the Publisher can use Rollback to reactivate it without modifying or rebuilding the current draft.

Manage collaborators and audience

The Owner finds in the Access panel two areas:

• Collaborators, to assign or revoke individual permissions for Project members;
• Runtime audience, to authorise application roles that can open the published Portal.

The audience does not replace membership in the Project. Removing a member, revoking a permission, or removing a role from the audience prevents subsequent unauthorised openings.

Troubleshooting

• The build does not start or remains pending: refresh the panel and, if the status does not change, report the message to the administrator.
• The release is not approvable: verify you have Publisher or Owner permission and that the build succeeded.
• The published Portal does not open: check Project membership, permission or audience, and active status.
• The remote target repeatedly returns to the sign-in page: close obsolete tabs, reopen the Portal with Open, and report the loop to the administrator if it continues; do not share authentication links.
• The remote target opens but dynamic widgets do not respond: verify that the Sybot platform is reachable; visible static content alone does not confirm that data and integrations are available.
• Published widgets look compressed or misplaced: create a new build and release with the current version, then deploy it; redeploying the previous release keeps its old artifact.
• Data or Workflow are denied: verify that the linked object is still accessible and that the release uses a current configuration.
• Deployment with Power BI is blocked: verify that every App owns data binding and variant has an active, diagnosed endpoint for the target or its environment.
• A diagnostic identifier appears: copy it without adding sensitive data and provide it to support.