How Published Apps Are Served

After the first publish, the application is live at its Application URL. Every subsequent request to that URL serves the most recently published version. In-progress edits and saved Working Copy changes are invisible to visitors until a new version is published.

At runtime, the platform decides what a visitor can see by evaluating two things simultaneously:

• Signed-in status — is the visitor an authenticated user or an anonymous visitor?

• Page privacy setting — is the page they're trying to reach marked Public or Private?

Visitors navigate the app using the navigation structure you configured in the builder. If a visitor lands on an unknown or moved URL, the runtime shows a not-found page or redirects as configured.

Page Privacy Settings

Each page in the builder has a Privacy setting in its Page Settings panel. The application as a whole can also have a global privacy setting. The two settings work together to determine who can reach which parts of your app.

Note: Anonymous visitors can only reach Public pages. If a visitor is not signed in, any attempt to navigate to a Private page is blocked — the runtime redirects them to sign in. Make only pages that are genuinely open to the world Public.

Privacy Settings Reference

Permissions and Roles

Public/Private privacy is a coarse gate — it controls whether unauthenticated visitors can reach a page at all. For signed-in users, a second layer of control applies: role-based permissions.

Access is determined by three stacked questions:

1. Can they reach the app? — Is the app published, and does the user have access to the workspace?

2. Can they open this page? — Does the page's Privacy setting allow their signed-in status, and does their role have permission for this page?

3. What can they do on this page? — What actions does their role permit (read, write, delete, etc.)?

Role and permission management is handled in the app's Settings tab under the Governance section, where you can manage users, teams, roles, and page-level permission assignments.

Troubleshooting: A User Can't Open a Page

When a user reports they cannot access a particular page, the root cause is almost always one of three things: the page is private and they are not signed in, their role lacks permission for that page, or the page URL has changed.

Common Causes

• Page is Private and user is not signed in. Anonymous visitors cannot reach Private pages regardless of the link they use.

• Role lacks permission for that page. The user may be signed in but assigned a role that does not have the page-level permission for this particular page.

• Page URL changed and the old link no longer resolves. If the page slug was updated after the link was shared, the old URL leads to a not-found page.

• App not published. If the app has never been published, no one can reach it at the Application URL.

Steps: Diagnosing a Page Access Problem

1. Confirm the application is published by checking the builder top bar or the Versions tab on the app detail page. If "Not Published" is shown, the app is not yet live.

2. Open the builder, navigate to the affected page, and open Page Settings. Check the Privacy field.

   • If Privacy is Private and the user is not signed in, they need either a login or the page must be made Public (only if truly open access is intended).

   • If Privacy is already set correctly, move to the next step.

3. Open the app's Settings → Governance section. Find the user's assigned role and verify that the role has the page-level permission for the affected page. Assign the correct permission if missing.

4. Confirm the page's current URL/slug. If it was recently changed, update any stale links shared with the user. The current slug is visible in Page Settings.

5. Have the user retry access in a fresh browser tab or incognito window to rule out cached redirects.

Embedding Applications in iFrames

Embedding a UnifyApps application inside another website or platform (such as a portal, intranet, or third-party SaaS product) requires passing two independent security gates. Passing one gate does not satisfy the other — both must be configured correctly for embedding to work.

Note: The two embedding gates are independent. Allowing a parent site in Frame-ancestors does not automatically permit that site's origin for API and sign-in calls. You must configure both settings separately.

Gate 1 — Frame-ancestors (Can the Site Frame Your App?)

The browser will refuse to render your application inside an iframe if the parent site's origin is not listed in your application's Content Security Policy (CSP) Frame-ancestors directive. This check happens at the browser level, before any page content loads.

Configure Frame-ancestors in the builder under Settings → Security → Frame-ancestors. Add the full origin of the site that will be embedding your app (for example, https://portal.example.com).

Gate 2 — Allowed Origins (Can the Site's Page Reach Your App's APIs?)

Even after Frame-ancestors is configured correctly, the embedded application still needs to make authenticated data requests and sign-in calls back to the platform. These requests are subject to CORS checking: the parent site's origin must be listed in the environment's allowed-origins configuration.

A common symptom of a missing CORS origin: the iframe renders (Frame-ancestors passed) but the application appears blank, shows a loading spinner indefinitely, or cannot complete sign-in. Browser developer tools will show CORS errors on API or authentication requests.

Note: Allowed origins are per-environment. An origin allowed in a test or staging environment does not automatically carry over to production. Configure each environment's allowed-origins list independently.

HTTPS Requirement for Embedding Origins

Most UnifyApps environments require embedding origins to be served over HTTPS. An origin like http://localhost pointing at a local development server will generally fail origin checks against a production environment, even if you add it to the allowed-origins list. Use HTTPS for any embedding origin that targets a production environment.

Steps: Setting Up iframe Embedding

1. Identify the exact origin of the parent site that will host the iframe. The origin is the scheme, hostname, and port (if non-standard) — for example, https://portal.example.com or https://intranet.corp.internal:8443.

2. In the builder, open Settings → Security → Frame-ancestors and add the parent site's origin to the list. Save the change and publish the application.

3. Contact your platform or environment administrator to add the same origin to the environment's allowed-origins (CORS) list. This step is environment-specific and may require access to environment configuration outside the application builder.

4. Verify the parent site is served over HTTPS if you are embedding in a production environment.

5. Test the embedding in the target portal. Open browser developer tools and check the Console and Network tabs for CSP or CORS errors:

   • A CSP frame-ancestors error means Gate 1 is still misconfigured — re-check Frame-ancestors in Settings → Security.

   • A CORS error on an API or auth request means Gate 2 is misconfigured — the origin is not on the allowed-origins list for this environment.

6. If the embedded app loads correctly but authentication fails, confirm that the environment's allowed-origins include the parent site, and that the user is signing in within the embedded context (some SSO configurations may require additional setup for cross-origin authentication).

Common Embedding Pitfalls

Frequently Asked Questions

What is the difference between a Public page and a Private page?

A Private page (the default) can only be accessed by signed-in users. Anonymous visitors attempting to reach a Private page are redirected to the sign-in screen. A Public page is accessible by anyone with the link, including unauthenticated visitors, with no sign-in required. You set the privacy for each page individually in the page's Page Settings panel inside the builder.

Does UnifyApps Applications support Single Sign-On (SSO)?

Yes. SSO configuration is a workspace and environment-level setting managed by your administrator, not a per-app Builder Settings option. Once SSO is configured for the workspace, users accessing any app in that workspace authenticate through the configured identity provider. For embedding scenarios, some SSO configurations may require additional cross-origin authentication setup — see the Embedding in iFrames section on this page for details on CORS and allowed-origins configuration.

How do I embed my UnifyApps app inside another website or portal?

Embedding requires passing two independent security gates. First, add the parent site's origin to your app's Frame-ancestors list in Builder Settings → Security → Frame-ancestors and republish. Second, have your platform administrator add the same origin to the environment's allowed-origins (CORS) list. Both gates must be configured — passing one alone is not sufficient. See the Embedding in iFrames section on this page for a step-by-step walkthrough and a table of common pitfalls.

Can I create a custom login page for my app?

The sign-in experience is controlled at the workspace and environment level by your administrator. You can customize branding elements (logo, colors) through the workspace and app-level theme settings, but building a fully custom authentication flow requires platform-level configuration. For scenarios requiring a white-labeled or entirely custom login UI, contact your UnifyApps account team to discuss available customization options.

Can I make my entire app publicly accessible without requiring any sign-in?

Yes. Set each page's Privacy setting to Public in the builder's Page Settings panel and ensure the app is published. Public pages are accessible to anonymous visitors without any sign-in. Be aware that public pages expose all displayed data to anyone with the URL — only make pages public when the content is genuinely intended for unauthenticated access. Role-based permissions still apply for data write operations even on public pages.