IFS Lobby Design: Creating Useful Dashboards in Aurena

Introduction

When organisations move from IFS Enterprise Explorer (IEE) in Apps 10 or earlier releases to IFS Cloud Web, one of the most visible changes is how dashboards, navigation, profiles, and home pages fit together. In IEE, a lobby was a common role-based starting point where users could see KPIs, launch quick actions, and navigate to their work. Many organisations relied heavily on lobbies and base profiles to shape the experience.

In IFS Cloud, that role has not disappeared: lobbies remain the dashboard canvas. Configuration Contexts are relevant when configurations need scoped variants, but they are not the role, security, profile, or lobby-design mechanism themselves.

This guide explores how to design effective IFS Cloud lobbies, how configuration contexts can scope presentation variants, and how that differs from the legacy Enterprise Explorer model. Exact lobby/configuration screens and element capabilities vary between Cloud releases, so preserve a working release-specific setup and validate it against the target environment.

---

The Evolution: From IEE Lobbies to IFS Cloud Lobbies

Enterprise Explorer Lobbies: The Earlier Model

In IFS Enterprise Explorer, base/user profiles commonly carried start-page, navigator, and personalisation choices around the lobbies a user could access. Multiple lobby pages could exist, but organisations often packaged a role-specific starting experience through base profiles. These lobbies were powerful:

• Role-based configuration: Profiles and permission sets packaged the starting experience for a business role
• Quick actions: Buttons linking to forms, reports, and transactions
• KPI displays: Static or dynamic metrics visible at a glance
• Visual branding: Color schemes and logos to distinguish environments or domains

However, this approach had limitations:

• Profile-driven variants: Different starting experiences often led to more base-profile variants
• Profile management overhead: Managing base profiles at scale became administratively complex
• Limited personalization: While lobbies could be customized, the per-profile structure made it hard to create nuanced user experiences
• Navigation context: The bridge between the lobby and the rest of the application was sometimes unclear

IFS Cloud Lobbies and Configuration Contexts

IFS Cloud provides Configuration Contexts to scope supported configuration variants. A context is a presentation/configuration selector, not an access-control role. Think of it as saying:

"Apply the configuration variant for Context Z where this configuration type and release support it."

This shift unlocks several advantages:

• Flexible presentation scope: Context variants can coexist with a global/default configuration
• Separation from security: Permission sets and business data-access rules still decide what users may see or do
• Governed variants: A small number of maintained contexts can support genuinely different page/lobby experiences
• Release-specific applicability: Not every configuration object or lobby capability uses contexts in the same way across releases

---

Understanding Aurena Configuration Contexts

Context Selection and Precedence

IFS can have product defaults, global configuration, context-specific configuration, and personalisation. In Apps 10 and several early IFS Cloud releases, a custom context could be selected explicitly by a navigator/lobby link or implicitly by mapping a user or user group to the context. If neither applied, configuration fell back through the global context to the product definition. Personalisation and the precise precedence rules vary by configuration type and release, so test the target version rather than assuming one universal chain.

How Contexts Work

Global/default configuration is the shared baseline where supported:

Global Context
├─ Supported page-layout configuration
├─ Supported navigator configuration
└─ Supported lobby configuration

Custom contexts identify intentional variants for supported configuration types:

Custom Context "Sales_EMEA"
├─ Sales lobby variant (where supported)
├─ EMEA-specific navigator shortcuts
└─ Falls back to global configuration for unchanged objects

Whether a user receives or selects that variant is configured through the supported context administration or explicit navigation mechanism for the release. It does not grant the lobby, page, projection, or underlying rows.

---

Setting Up Role-Based Dashboards: Step by Step

Step 1: Plan Audiences, Then Decide on Contexts

Before creating contexts, map your organizational structure to context needs:

Example: Manufacturing Organization

If contexts are justified, their identifiers should be:

• Descriptive: MaintenancePlanner, not S1
• Consistent: Follow the naming rules enforced by the target context administration page
• Semantically clear: Future admins should understand the intent

Step 2: Establish the Presentation Scope

Create the context in the context-administration tooling provided by the target release, then select it in Page Designer, Navigator Designer, or the relevant configuration designer when that object supports contextual variants. Record its purpose, owner, applicable configuration types, implicit mapping or explicit entry point, and review date.

If the requirement is simply “give production managers this lobby,” a functional permission set, a shared lobby/homepage/profile configuration, and business-data access may be sufficient. Do not create a context merely as a substitute for a role.

Step 3: Configure Your Lobby Dashboard

IFS Cloud uses lobbies to display dashboard content. The 23R2/24R2 technical documentation separates lobby work into three designers under Solution Manager > Configuration > Lobby (menu wording varies by release):

• Lobby Data Source Designer defines or reuses the data contract and its parameters
• Lobby Element Designer turns that data into a counter/value, list, chart, text/image, or navigation experience
• Lobby Page Designer arranges elements, defines page parameters and client type, and can configure page auto-refresh

A lobby solution is therefore composed of:

• Page definition: Layout, page parameters, client type, and refresh behaviour
• Element definitions: Counters/values, lists, charts, text, images, or other types supported by the release
• Datasource and navigation contracts: The governed data behind each element and its drill-down target

To set up a lobby for your context:

1. Open an existing lobby or create a new page through Lobby Page Designer in a non-production environment
2. Select the intended configuration context only if the release supports contextual lobby configuration and the variant is justified
3. Add lobby elements:
   • List elements: Display filtered records (e.g., open work orders)
   • Counter/value elements: Show a metric (e.g., production rate)
   • Navigation-enabled elements: Link to key transactions or filtered pages
   • Charts: Visualise trends using supported lobby chart elements or a governed analytical link/embedding route

Best Practice: Keep the first version small enough that a process owner can reconcile every number and test every drill-down. Export/version the data source, element, and page definitions together so the lobby can be reproduced.

Step 4: Define a KPI Counter or Value

KPI counters and values are the visual backbone of an effective dashboard. The exact element names vary, but the workflow is consistent:

1. In Lobby Data Source Designer, create or reuse a supported SQL or Projection Data Source; in 24R2, Query Projections can also back Projection Data Sources
2. Define its input/page parameters and output columns, then test it with representative data and permission sets
3. In Lobby Element Designer, create a counter/value element and bind its value to a datasource column such as an already-calculated count or sum
4. Define the display:
   • Primary value: The main metric (e.g., "847 units")
   • Secondary metric: Optional comparison (e.g., "↓ 5% from yesterday")
   • Threshold coloring: Green (good), amber (warning), red (critical)
5. Add the element to the page in Lobby Page Designer and set page auto-refresh only where the freshness need justifies its cost

Example KPI Tile Configuration:

Element Name: Production Throughput
Data Source: ProductionThroughput (governed lobby datasource)
Value column: QuantityProduced
Primary Display: {metric} units/shift
Secondary Metric: Variance from target
Threshold: >1000=green, 800-999=amber, <800=red
Refresh Rate: Every 5 minutes

Lobby datasources and elements can also use page parameters so users can narrow metrics:

Filter intent: current permitted site(s), and shift date within the last seven days

Map page parameters only with syntax offered by the target Lobby Data Source/Page Designer. #COMPANY_ID#, #PERSON_ID#, and #USER_ROLE# are not universal IFS lobby substitution variables. Released lobby navigation documentation instead shows release-specific forms such as page parameters and $Company$/$[ATTRIBUTE] placeholders. The datasource must independently enforce the applicable site/company/data scope.

Step 5: Configure Filtered Lists on Dashboards

Display quick-access lists of records on your dashboard:

1. Create or reuse a datasource that returns the limited columns and rows the list needs
2. Create a List element in Lobby Element Designer and bind it to that datasource
3. Configure filtering and navigation:
   • Default filters: Filter by status, date, site, etc.
   • Sortable columns: Let users click to re-sort on-the-fly
   • Click-through: Clicking a row navigates to the detail page

Example: Warehouse Dashboard Filtered List

List: Open Purchase Orders
Data Source: OpenPurchaseOrders
Default Filters:
  - status is not Received
  - expected date is within the next seven days
Columns: Order #, Vendor, Amount, Expected Date
Action: Click row → Opens PO detail page

This gives warehouse staff an at-a-glance view of orders arriving soon, reducing the need to navigate and filter manually.

Step 6: Grant and Assign the Experience

Use the target release's supported permission-set, lobby, profile/homepage, navigator, and context assignment mechanisms. Where context mapping is supported, a user or group can receive a custom context implicitly; earlier context guidance also describes mappings based on supported attributes such as default company. A navigator entry or lobby link can select a context explicitly. Keep these concerns separate:

• Permission sets grant the lobby, page, projection, and operations.
• Company/site/project or domain controls restrict the business data.
• Profile/homepage/navigation configuration determines the user's starting experience.
• A configuration context selects a presentation variant where supported.

Test with a normal user. A user who can select a context must not gain data or action access by doing so.

Step 7: Test Navigation & Context Switching

Test every supported route into the lobby: assigned homepage, navigator link, direct environment-neutral link, and any context selector documented for that release. Apps 10 and several early Cloud releases used an explicit directive such as lobby/<lobby-id>;scope=<context-id>; retain that syntax only for a release that documents it and build the route without an environment-specific host name. If a context can be selected through navigation, that is further proof that it is not a security boundary.

---

Comparing IFS Cloud and Enterprise Explorer Lobby Delivery

Key Differences

Migration Considerations

If you're moving from IEE to IFS Cloud Web:

1. Inventory EE profiles and lobbies: Record elements, data sources, security dependencies, owners and usage.
2. Retire or consolidate: Do not migrate duplicate tiles or metrics with no business owner.
3. Redesign lobbies: Rebuild the surviving decision journeys in Lobby Designer and link to Cloud pages.
4. Reconcile role and data access: Profiles, permission sets and contexts solve different problems; map requirements rather than object counts.
5. Document variants: Maintain a register of global/context-specific configuration, audience assignment and review dates.

---

Best Practices for Aurena Dashboard Design

1. Keep Dashboards Focused

Avoid information overload. A production manager's dashboard should show:

• 3–5 critical KPIs (throughput, defects, utilization, safety incidents, OEE)
• 2–3 actionable lists (open work orders, pending approvals, overdue items)
• 2–3 navigation tiles (Create PO, Check Inventory, View Reports)

Total tiles: 7–11. More than 15 tiles becomes noise.

2. Use Real-Time or Near-Real-Time Data

Choose refresh intervals from the decision's freshness requirement and datasource cost. A safety exception may need near-real-time treatment; a monthly margin does not. Avoid static metrics that look live and aggressive polling that overloads the homepage.

Example service targets to agree and test (not IFS defaults):
- Critical operational exception: as fresh as the supported source can safely deliver
- Operational KPI: minutes, where actionability justifies it
- Strategic KPI: hourly/daily/monthly according to its accounting basis

3. Provide Context with Secondary Metrics

Don't show just numbers. Add comparisons:

KPI Tile: Revenue (This Month)
Primary: $2.5M
Secondary: +8% vs. last month (trend arrow)
Threshold: Green (>$2M)

Users instantly understand performance relative to expectations.

4. Enable Quick Navigation

Add 2–3 navigation tiles that link directly to the most common transactions:

Tile: Create Production Order
Link: an environment-neutral navigation target to the supported Production Order page
Icon: Plus symbol

This reduces click depth and improves accessibility.

5. Filter Data by User Context

Use the business object's supported data-access controls and any documented lobby parameters to make dashboards relevant:

KPI: My Open Tasks
Filter intent: assigned to the authenticated person and within their permitted company/site scope
Result: each user sees only the tasks authorised by the datasource and business rules

6. Version Your Contexts

As your organisation evolves, export/version the supported lobby and configuration package through change control. Keep the functional context name stable; do not create permanent v1, v2, and trial contexts for every layout edit. Use a governed pilot context only when parallel testing is genuinely required, then retire it.

7. Document the Design

Maintain a shared reference for each lobby and any context variant:

---

Troubleshooting Common Issues

Issue: User Not Seeing the Expected Context

Cause: The wrong lobby/profile/configuration variant is assigned, a context-specific configuration is unpublished, or a personalisation/cache takes precedence.

Solution:

1. Verify the published lobby/configuration, implicit context mapping, or explicit navigation directive applicable to the release.
2. Check lobby/page/projection permission-set grants and profile/homepage selection.
3. Check personalisation precedence and retry in a clean representative session.
4. Test the context through a supported selector, mapped user, navigator entry, or release-documented scope link.

Issue: KPI Tile Showing Incorrect Data

Cause: Filter or projection misconfiguration, or stale data cache.

Solution:

1. Verify the element is bound to the intended lobby datasource and output column
2. Check filter syntax (case sensitivity, quote marks)
3. Test with one known status/site/date condition before combining filters
4. Check refresh interval; immediate refresh may show cached data
5. Review the datasource, lobby, page, and projection grants in the target release's permission-set administration

Issue: Ambiguous Navigation Error

Cause: Multiple published variants, profile/personalisation precedence, or ambiguous navigation/configuration assignment.

Solution:

1. Review the supported assignment and precedence rules for that release.
2. Remove duplicate/obsolete lobby or navigator variants.
3. Verify that the navigation target and key/filter context are unambiguous.
4. Document any intentional pilot or escalation variant and its retirement date.

Issue: Navigator Items Not Showing in Custom Context

Cause: Navigator configuration not defined for the context; fallback to global.

Solution:

1. Switch to your context in Navigator Designer
2. Explicitly configure or override navigator entries
3. Ensure the intended lobby/context/profile assignment is published
4. Test through the supported navigator and context-selection route

---

Advanced: Combining Lobbies with Power BI

IFS Cloud 24R2 documents Power BI properties as an Element Designer element type. For that release, create and configure the element in Lobby Element Designer, then place it on the lobby page. For other releases, confirm the equivalent supported element or use a governed navigation link. In either case, Microsoft licensing, tenant security, and the customer's identity architecture still apply:

1. Confirm the release supports the intended Power BI element, link, or embed pattern.
2. Configure the Power BI workspace, report, identity and licensing outside the lobby definition.
3. Implement Power BI row-level security in the semantic model and prove the viewer identity reaches it; a shared service identity can give every viewer the same scope.
4. Configure semantic-model refresh according to source capacity and freshness requirements.

There is no universal [UserRole] = #USER_ROLE# bridge from IFS to Power BI RLS. Keep operational exception lists in IFS when users need to act immediately, and use Power BI for governed analysis when the supported identity path is proven.

---

Key Takeaways

1. Contexts do not replace roles or profiles: They scope supported configuration variants; lobby/profile assignment, permission sets and data access remain separate.

2. Lobbies are your dashboard canvas: Use lobbies with KPI tiles, filtered lists, and navigation links to create focused, actionable homepages.

3. Assign the experience through supported mechanisms: Keep context selection, lobby/profile assignment, permission sets and business-data scope explicit.

4. Navigation must be supported and environment-neutral: Do not depend on undocumented context URL suffixes.

5. Less is more: 7–11 tiles per dashboard keeps users focused. KPIs should include comparisons and thresholds.

6. Test thoroughly: Use the Lobby Page, Element, and Data Source designers, the supported assignment/context route, representative permission sets, and real drill-downs.

7. Document your design: Maintain a registry of contexts, their purposes, and associated user groups for maintainability.

---

Conclusion

The shift from Enterprise Explorer to IFS Cloud changes lobby design, navigation, profile/configuration and service security, but lobbies have not been replaced by contexts. By defining KPI contracts, using Lobby Designer, governing any context variants, and testing permission/data scope, you can create dashboards that inform users and drive the right actions.

Whether you're migrating a legacy IFS system or building in IFS Cloud, invest time in designing the lobby contract—and any context variants—thoughtfully. A well-designed dashboard ecosystem pays dividends in user adoption, efficiency, and operational visibility.

---

Resources

• IFS Cloud technical documentation
• IFS Cloud 24R2 Lobby Configuration
• IFS Cloud 24R2 Data Source Designer
• IFS Cloud 24R2 Element Designer
• IFS Cloud 22R1 Configuration Context
• IFS Community: Discussions on context setup, lobby design, and best practices