PracticeVideosBlogFlashcards

Free exam prep

Appian Certified Associate Developer (ACD101)

Practice QuestionsStudy Guide

10.3 Appian Sites, Navigation & Portal Configuration

Key Takeaways

  • Appian Sites provide customized, branded digital workspaces tailored to specific business roles and user personas, replacing the generic multi-purpose Tempo feed.

  • Current sites support up to ten top-level pages or page groups; only Interface pages can be placed inside page groups.

  • Current page types include Action, Interface, Record List, and supported Process HQ library/dashboard pages.

  • Page-level visibility expressions conditionally hide or display navigation tabs based on user roles, but do NOT replace backend object-level security on the underlying records or interfaces.

  • Appian Portals provide unauthenticated, publicly accessible web experiences for anonymous external users without requiring Appian user logins, whereas Appian Sites strictly require authenticated user sessions.

Last updated: October 2026

Appian Sites, Navigation & Portal Configuration

Quick Summary: Appian Sites deliver role-tailored, branded web applications for authenticated business users, with up to ten top-level pages or page groups and supported Action, Interface, Record List, and Process HQ page types. While Sites govern internal workflows with granular page visibility rules and corporate styling, Appian Portals extend Appian's reach to anonymous, unauthenticated public web users (such as citizen intake forms or public supplier onboarding) without requiring individual Appian user accounts.

Appian Sites Architecture & Strategic Purpose

In early versions of the Appian platform, business users accessed enterprise applications primarily through Appian Tempo—a unified social collaboration portal featuring five standardized tabs: News, Tasks, Records, Reports, and Actions. While Tempo established a centralized intranet hub, enterprise organizations required dedicated, brand-aligned, and persona-focused user experiences. Appian introduced Sites to solve this requirement.

An Appian Site is a customized digital workspace designed for a specific target audience or business persona (such as Claim Adjusters, Underwriting Managers, or Customer Service Representatives). Sites allow developers to create streamlined, role-specific applications that isolate users from unrelated corporate noise.

+-----------------------------------------------------------------------------+
|                        APPIAN SITES vs. APPIAN TEMPO                        |
+-----------------------------------------------------------------------------+
|  Dimension           | Appian Tempo                 | Appian Site           |
|  --------------------+------------------------------+-----------------------|
|  Target Audience     | Broad enterprise workforce   | Specific user persona |
|  Branding Freedom    | Global platform theme        | Custom logo, colors,  |
|                      | (Single corporate style)     | and header styles     |
|  Navigation Layout   | Fixed 5 tabs (News, Tasks,   | Up to 10 customizable  |
|                      | Records, Reports, Actions)   | pages or page groups  |
|  User Interface Feel | Social feed / Task inbox     | Custom business app  |
|  Modern Best Practice| Maintained for collaboration | Standard for apps     |
+-----------------------------------------------------------------------------+

Strategic Advantages of Sites

  1. Role Focus: Users see only the actions, dashboards, and records pertinent to their daily operational responsibilities.
  2. Custom Branding: Each site can apply unique corporate logos, favicons, navigation banner colors, accent highlights, and dark/light navigation bar styling.
  3. Simplified Ergonomics: Pinned header or sidebar navigation minimizes cognitive overhead and reduces training overhead for business users.

Site Structure & Page Configurations

When designing an Appian Site object in Appian Designer, developers configure the navigation hierarchy and define the behavior of individual pages.

+-----------------------------------------------------------------------------+
|                       APPIAN SITE NAVIGATION STRUCTURE                      |
+-----------------------------------------------------------------------------+
|  [Corporate Logo]    Page 1       Page 2       Page 3 (Group)    [User]     |
|  =============================================================              |
|                      (Action)   (Record Type)  ┌─────────────┐              |
|                                                │ Child Page A│ (Interface)  |
|                                                │ Child Page B│ (Interface)     |
|                                                └─────────────┘              |
+-----------------------------------------------------------------------------+

The 10 Top-Level Navigation Item Limit

An Appian Site enforces a hard architectural boundary: it can contain up to 10 top-level navigation items. A top-level item can be:

  • An Individual Page (directly displaying an action, interface, record type, or report).
  • A Page Group (a dropdown folder in the navigation bar holding supported Interface child pages).

By leveraging Page Groups, developers can organize rich, multi-page applications containing dozens of sub-pages while strictly respecting the 10 top-level navigation constraint.

Common Current Page Types

Page TypeUnderlying Design ObjectOperational Behavior & User Flow
ActionProcess ModelDirectly launches the process model's Start Form. When submitted, the user can be directed to a specified confirmation interface or returned to the site. Ideal for "Submit Expense Claim" or "Initiate Onboarding".
InterfaceSAIL Interface RuleRenders a custom SAIL interface using supported layouts or a collection of components. Used for executive KPI dashboards, operational queues, or landing hubs.
Record TypeRecord Type ObjectDisplays the standard Record List of the specified Record Type, complete with full-text search, user-defined filters, export to Excel, and record view drill-downs.
Process HQ - Full Library / DashboardSupported Process HQ contentEmbeds the selected report library or dashboard, subject to its access requirements.

Navigation Layouts, Branding & Visual Styling

Developers configure the visual appearance and ergonomic layout of a Site via the Site Designer properties:

Navigation Bar Styles

  1. Header Bar Navigation:
    • Positions navigation tabs horizontally across the top of the screen.
    • Best suited for applications with 3 to 5 flat pages, executive dashboards, or wide data tables requiring maximum horizontal screen real estate.
  2. Sidebar Navigation:
    • Positions navigation items in a vertical collapsible sidebar drawer on the left side of the viewport.
    • Ideal for complex applications utilizing Page Groups with deep navigation trees, nested hierarchies, or operational workflows with numerous sub-sections.

Branding Parameters

  • Web & Mobile Logos: Custom image assets displayed on the leading edge of the navigation bar.
  • Favicon: Custom browser tab icon.
  • Color Scheme: Developers configure the Header Color (background of the navigation bar), Selected Page Color (accent underline or pill for the active tab), and Accent Color (governing primary buttons, links, and highlights across the entire site).
  • Navigation Bar Style: Supports "Standard" (light background) or "Dark" navigation themes.

Site Security & Page-Level Visibility Expressions

Access control in Appian Sites operates on a dual-layer architectural model: Site Object Security and Page-Level Visibility Expressions.

+-----------------------------------------------------------------------------+
|                        SITE DUAL-LAYER ACCESS CONTROL                       |
+-----------------------------------------------------------------------------+
|                                                                             |
|  LAYER 1: Site Object Role-Based Security (ACL)                             |
|  - Administrator: Full design and editing rights.                           |
|  - Viewer: Required for end users to navigate to the site URL.              |
|    (Users without Viewer rights receive an HTTP 403 Forbidden error)        |
|                                                                             |
|  LAYER 2: Page-Level Visibility Expressions (Dynamic UI Filter)             |
|  - Expression evaluated per user: rule!APP_isUserInGroup(loggedInUser(),...)|
|  - If TRUE:  Page tab appears in navigation bar.                            |
|  - If FALSE: Page tab is completely hidden from navigation.                 |
|                                                                             |
|  CRITICAL RULE: Page visibility hides the UI tab; it does NOT secure the   |
|  underlying Record Type or Process Model! Backend object ACLs must still    |
|  be enforced independently.                                                 |
+-----------------------------------------------------------------------------+

Page-Level Visibility Expressions

Each page within a site features a Visibility expression field. Developers write a SAIL expression returning a boolean (true or false):

/* Visibility expression on 'Executive Audit' site page */
a!isUserMemberOfGroup(
  username: loggedInUser(),
  groups: { cons!SEC_GRP_EXECUTIVE_MANAGERS }
)
  • If the expression evaluates to true, the page tab is visible to the logged-in user.
  • If false, the page tab is omitted from the navigation bar.

Caution

Critical Exam Distinction: UI Visibility is NOT Object Security. A page visibility rule controls navigation/page visibility. If a malicious or curious user discovers the direct URL to the underlying Record Type or Interface, they can access the data if the underlying object lacks strict Role-Based Access Control (RBAC). Developers must always secure the underlying Record Types, Expression Rules, and Process Models using object-level security.

Appian Portals: Anonymous Public Access vs. Authenticated Sites

A central topic on the ACD101 exam is the architectural contrast between Appian Sites and Appian Portals.

Historically, all Appian applications required users to log in with an authenticated user account (via SAML, LDAP, or native Appian credentials). However, enterprise organizations frequently need to capture data from external, unauthenticated users—such as public citizens reporting road potholes, prospective college students submitting admissions inquiries, or vendors registering bids. Appian Portals provide this capability.

+-----------------------------------------------------------------------------+
|                  APPIAN SITES vs. APPIAN PORTALS COMPARISON                 |
+-----------------------------------------------------------------------------+
|  Feature             | Appian Sites                 | Appian Portals        |
|  --------------------+------------------------------+-----------------------|
|  User Authentication | STRICTLY REQUIRED            | UNAUTHENTICATED       |
|                      | (Named user login session)   | (Anonymous web users) |
|  --------------------+------------------------------+-----------------------|
|  User Licensing      | Contract-specific authenticated access | Contract-specific portal entitlements; verify |
|                      | terms must be checked        | the applicable licensing terms       |
|  --------------------+------------------------------+-----------------------|
|  Hosting Model       | Internal Appian Application  | Serverless, scalable  |
|                      | Server tier                  | edge cloud runtime    |
|  --------------------+------------------------------+-----------------------|
|  Target Use Cases    | Employee task completion,    | Public forms, citizen |
|                      | internal review dashboards   | intake, vendor signup |
|  --------------------+------------------------------+-----------------------|
|  Backend Connection  | Direct access to Data Fabric | Service Accounts,     |
|                      | and Process Engines          | Web APIs, Integrations|
+-----------------------------------------------------------------------------+

Public Access and Service Identity

A Portal makes the intended public interface available without an Appian user login. Its supported data and process operations must be configured with an appropriate service identity and access. Check function compatibility and use supported integrations/Web APIs when direct access is unavailable.

Anonymous access is not a grant to all enterprise data. Return only the intended public fields, validate submitted values, and secure uploads and process starts. A service account's broad privileges must not accidentally become a public query API. Verify actual licensing and capacity terms rather than assuming an unlimited session model or zero impact on backend systems.

Realistic Scenario: Supplier Self-Service Portal & Procurement Site

A global manufacturing enterprise implements an end-to-end procurement system utilizing both an Appian Portal and an Appian Site:

  1. External Public Registration (Appian Portal):

    • Prospective suppliers visit https://onboarding.globalmfg.com.
    • No login is required. The portal presents an anonymous public intake interface.
    • Suppliers enter their company tax identifier, upload W-9 PDF documents via a!fileUploadField(), and provide banking details.
    • Upon submission, the portal invokes a secure Appian Web API under a Service Account, writing the record to the database and initiating an internal approval process.

  2. Internal Procurement Management (Appian Site):

    • Internal procurement officers log into https://globalmfg.appiancloud.com/suite/sites/procurement.
    • The site uses Header Bar navigation with corporate dark blue branding and 4 pages:
      • Page 1 (Interface): "Procurement KPI Hub" displaying charts and open task counts.
      • Page 2 (Action): "Create Purchase Order" launching a process model start form.
      • Page 3 (Record Type): "Suppliers Directory" displaying the full synced record list of approved suppliers with user filters for region and commodity.
      • Page 4 (Interface): "Compliance Audit Log" displaying financial audit reports. This page is configured with a Page Visibility Expression (a!isUserMemberOfGroup(loggedInUser(), cons!GRP_PROCUREMENT_MANAGERS)), rendering it visible only to managers.

Common Exam Traps & Architecture Guidelines

Warning

Current Navigation Limit: A site can have up to ten top-level pages or page groups. Eight top-level pages fit that limit. Page groups organize related Interface pages; Action and Record List pages cannot be placed inside those groups.

Warning

Common Exam Trap 2: Using Appian Sites for Anonymous Public Intake. When an exam question specifies that external users without Appian accounts must submit public applications, registrations, or quotes, the answer is never an Appian Site with a shared login credential. Sharing user accounts violates security, auditing, and licensing rules. The correct architectural solution is Appian Portals.

Tip

Site Page Type Selection: Use the Action page type when a user's sole objective on that tab is to initiate a workflow (such as a request form). Use the Record Type page type when the objective is searching, filtering, and browsing existing business entities. Use the Interface page type when presenting multi-component operational dashboards combining charts, metric cards, and custom task grids.

Source checked 2026-10-18: Appian site navigation and page types.

Test Your Knowledge

What is the current maximum number of top-level pages or page groups in an Appian Site?

A

3

B

5

C

10

D

Unlimited

Test Your Knowledge

An organization requires a publicly accessible web form where anonymous citizens can submit infrastructure repair requests and upload photos without logging in or possessing an Appian user account. Which Appian capability should be implemented?

A

An Appian Site configured with a shared generic user credential.

B

An Appian Tempo News feed post with public broadcasting enabled.

C

An Appian Embedded SAIL interface hosted inside an unauthenticated iFrame.

D

An Appian Portal.

Test Your Knowledge

A developer configures a page-level visibility expression on an Appian Site page that evaluates to false for non-manager users. Which statement accurately describes the resulting security and access behavior?

A

The underlying Record Type and process models mapped to the page are automatically secured against non-manager access.

B

The page tab is hidden from non-managers in the site navigation, but object-level security on the underlying interface or record must still be configured independently.

C

The Appian platform automatically revokes Viewer permissions on all application objects for non-manager users.

D

Non-managers attempting to access the site URL are immediately logged out of Appian.

Sections you finish are checked off in the contents.

Up Next

11.1 Expression Rule Architecture & Function Namespaces

Chapter 11: Expression Rules & Functional Data Manipulation