What Is a Slug?
A slug is the URL-safe identifier for a page — the segment of the URL path that corresponds to that page. When you create a page named "Order Details", UnifyApps auto-generates the slug order-details and constructs the URL /app-slug/order-details.
Slugs and page names are independent: you can rename a page in the Pages panel without changing its slug (and therefore without breaking its URL), and you can customise the slug independently of the display name. This separation is intentional — the display name is what users read in the UI; the slug is a technical contract that should be stable once the page is published.
Configuring a Slug
Auto-generated slugs are good starting points but you will often want to customise them — to match an API path convention, to keep URLs short, or to use a preferred canonical form.
Open the rename slug dialog: In the Pages panel, right-click the page whose slug you want to change. Select Rename Slug from the context menu. The dialog shows the current slug and a preview of the full URL it produces.
Enter the new slug: Type the new slug value. The field enforces valid characters in real time — invalid characters are highlighted and the Save button is disabled until the slug is valid. The URL preview updates as you type.
Check for conflicts: UnifyApps checks for slug uniqueness within the same folder. If another page at the same level already uses the new slug, you will see a conflict error. Choose a different slug value.
Save and add a redirect if needed: Click Save. If this page is already published and may have been bookmarked or linked externally, navigate to App Settings → Redirects and add a redirect from the old slug to the new one.
Slug Validation Rules
UnifyApps enforces the following rules on page slugs:
| Rule | Detail |
| Allowed characters | Lowercase letters (a–z), digits (0–9), and hyphens (-). No spaces, underscores, dots, slashes, or uppercase letters. |
| Length | 1–80 characters. Shorter slugs produce shorter, more shareable URLs. |
| Must not start or end with a hyphen | -orders and orders- are invalid. order-details is valid. |
| Unique within a folder | Two pages in the same folder cannot share a slug. Two pages in different folders may have the same slug — their full paths will still be different. |
| Reserved slugs | A small set of slugs is reserved by the platform: api, auth, health, static. Using these will trigger a conflict error even with no other pages present. |
Tip: Slugs that read as nouns (orders, order-detail, settings) produce cleaner, more bookmarkable URLs than verb-based slugs (view-orders, edit-settings). Prefer concise identifiers over descriptive phrases.
Visibility Settings
Visibility controls two separate things: whether the page appears in navigation menus (sidebar, bottom bar, drawer) and whether users are allowed to reach the page at all. These two things can be set independently.
| Visibility mode | Appears in nav? | Accessible by URL? | Who can access |
| Public | Yes (shown to all) | Yes | Any visitor, including unauthenticated users. Use for landing pages, login pages, public-facing content. |
| Authenticated | Yes (shown to signed-in users) | Yes (redirects unauthenticated users to login) | Any signed-in user, regardless of role. The default for most pages in internal tools. |
| Role-based | Yes (shown only to users with matching roles) | Yes (403 for users without the required role) | Only users whose role matches the configured permission rule. Roles and rules are configured in Governance → Permissions. |
| Hidden | No (never shown in nav) | Yes (if the user navigates directly) | Anyone who knows the URL. The page is reachable by direct link but not discoverable through the navigation menu. Use for contextual detail pages reached only via programmatic navigation. |
Setting a Page's Visibility
Visibility is set in two places depending on the type of control you need:
Public / Authenticated: Page Settings → Privacy dropdown. Available options are Public and Private (Authenticated). This is the primary access gate.
Role-based: Page Settings → Permissions section. Add permission rules here. Each rule specifies a role and an action (Allow / Deny). Role-based permissions layer on top of the Privacy setting — a Private page with an admin-only permission rule is accessible only to authenticated users who are also admins.
Hidden from nav: Navigation settings (App Settings → Navigation → Content tab) → find the menu item for this page → toggle the visibility eye icon off. Alternatively, do not add the page to the navigation at all — pages not in the nav are hidden by default.
Conditional Visibility
In addition to the static visibility modes above, you can bind the visible property of individual navigation menu items to a dynamic expression. This lets the same page appear or disappear in the nav based on runtime state — the current user's role, a feature flag, or any other data binding.
📄 Example — Role-based nav visibility
In the Navigation content panel, select the menu item for your "Admin Console" page. Find its Visible property and bind it to:
{{ user.role === "admin" }}
Non-admin users will not see the "Admin Console" item in the menu at all. The page itself may still be accessible by URL depending on its Permission setting — conditional nav visibility does not replace access control, it complements it.
Warning: Hiding a page from the navigation menu does not prevent a user from navigating to it directly by URL. To restrict access, configure the page's Permissions in Page Settings. A user who guesses or discovers the URL can still reach the page if no permission rule blocks them.
How Visibility Affects Navigation Components
UnifyApps automatically reconciles navigation menus with page visibility settings at publish time:
Hidden pages are silently removed from the sidebar, bottom tab bar, and drawer menu. They do not appear as greyed-out items.
Role-restricted pages are removed from nav for users who do not have the required role. The menu collapses gracefully — no placeholder or lock icon is shown.
Public pages appear in the nav even when the user is not signed in, provided the nav itself is visible in unauthenticated mode.
Mobile bottom bar applies an additional cap of 5 items and automatically removes hidden/restricted items before that cap is applied.
Frequently Asked Questions
Can I rename a slug after the app is live?
Yes, but with caveats. Changing a slug changes the page's URL immediately on the next publish. Any existing bookmarks, external links, or hardcoded navigation targets pointing to the old URL will break. Always add a redirect from the old path to the new one in App Settings → Redirects before publishing a slug change. Within your UnifyApps app itself, all Go to Page actions use the page identifier (not the URL string), so internal navigation updates automatically — only external links and bookmarks are affected.
What is the difference between Hidden visibility and a Permission deny rule?
Hidden visibility removes the page from navigation menus but does not restrict URL access. Anyone who navigates directly to the URL can still reach the page. A Permission deny rule actively prevents access — users without the required role receive a 403 response (or are redirected, depending on your configuration) even if they navigate directly to the URL. For most secure pages, use both: hide from nav so the page is not discoverable, and add a permission rule so direct URL access is also blocked.
Do slugs need to be unique across the entire app?
No — slugs must only be unique within the same folder. Two pages in different folders may share a slug. For example, you could have /orders/detail and /invoices/detail — both use the slug detail but live in different parent folders, giving them distinct full paths. However, keeping slugs globally meaningful (e.g. order-detail vs invoice-detail) makes URLs more readable and reduces confusion when sharing links.