Iris Portal Configuration Settings

The Iris Portal is the front-end gateway for Olympus-Grid’s micro-frontend architecture. It enables dynamic routing of domain-based requests to appropriate static resource bundles, allowing virtually unlimited site deployments from a single configuration file.

The configuration allows a flexible front-end routing engine for Olympus-Grid that enables micro-frontend rendering across multiple domains and namespaces using declarative routing rules. Its core power lies in its ability to host unlimited client-facing sites through a single JSON configuration file, with clean separation of resources and namespaces.

This document outlines all configuration options available within the Iris Portal JSON model, including default settings, router rules, and architectural considerations.

Default Site Settings

Setting	Description
portalName	Internal name of the portal used in logs or system UI.
pageTitle	Title displayed in the browser tab or window.
bundleResource	Default static resource bundle to load for fallback/default rendering.
bundleNamespace	Salesforce namespace where the static resource is deployed.
maintenanceMode	Boolean flag to activate global maintenance mode.
banner	Whether a banner is shown to users at the top of the page.
bannerText	Text content of the banner.
bannerColor	Background color for the banner in hex format.
textColor	Text color of the banner.
bannerCanClose	Boolean that determines whether users can dismiss the banner.
bannerTimeOn	Timestamp when the banner becomes visible (UTC).
bannerTimeOff	Timestamp when the banner disappears (UTC).
allowBundleDomain	If true, allows static resources to be injected at runtime (NOTE - THIS IS FOR DEVELOPMENT ONLY AND NOT SAFE FOR PRODUCTION)
routerRules	Object, See Below

Routing Rules

Router rules dynamically determine which static bundle to serve based on domain and traffic conditions. Each rule is evaluated in order of sequence.

{
  "description": "Friendly name for the rule",
  "sequence": 100,
  "active": true,
  "conditions": {
    "domain": "example.olympus-grid.com"
  },
  "percent": 50,
  "bundleResource": "resource_name",
  "bundleNamespace": "optional_namespace",
  "startTime": "",
  "endTime": ""
}

Router Rule Settings

Setting	Description
description	Human-readable description for auditing/debugging.
sequence	Order in which the rule is evaluated (lower numbers are processed first).
active	If false, the rule is ignored.
conditions.domain	Matches request by domain. Wildcards can be implemented later if needed.
percent	Load balancing percentage (e.g., for A/B testing or canary deployments).
bundleResource	The name of the static resource bundle to load.
bundleNamespace	Salesforce namespace where the resource is deployed. Leave blank for none.
startTime, endTime	Optional fields for time-based routing control. (UTC format)

Micro Front-End Architecture

Each route can serve a completely different application (or version) via:

• Same Namespace: Default bundles deployed in the host org.

• Cross-Namespace: Serve bundles from other managed packages.

• Development Mode: If allowBundleDomain is true, the bundle can come directly from the developers local workstation supporting rapid development with hot reloading.

This makes it easy to:

• White-label portals per customer

• A/B test frontend bundles

• Canary or multi-variable testing

• Roll out region-specific portals

• Allow customers to own their own deployment

• Runtime switching between versions

• Seamless multitenant experiences

• Allow react developers to iterate faster than ever

All from a single Force.com Site (or Digital Experience)

Sticky Sessions

Once a routing rule has responded with a bundle, that bundle will continue to be served without further evaluation of the routing rules for the duration of the sticky session (currently 24 hours).

• To remove the sticky session manually, delete the bundleResource cookie

SSL Certificate Considerations

Salesforce currently supports a maximum of 50 active SSL certificates per org. To scale beyond this:

• Use wildcard certificates (e.g., *.olympus-grid.ai) (if supported by Salesforce)

• Delegate some routing to CloudFront or other CDNs

• Utilize the Salesforce domain name endpoint which is already protected by TLS

• Consider routing low-traffic or internal domains without SSL termination at Salesforce

Best Practices

• Use consistent domain naming (e.g., region.client.olympus-grid.ai)

• Keep bundleNamespace blank for client-hosted bundles

• Apply sequence carefully to ensure fallbacks are respected

• Use percent for rolling deployments or canary testing

Known Limitations

Constraint	Current Limit	Notes
SSL Certificates	50	Limited by Salesforce certificates for custom domains. Consider using a wildcard or external CDN (if supported)
Rule Count	Not hard-limited	Practical limit depends on performance and deployment size.
Static Resource Size	5MB per file	Use GZIP + modular bundling.
Salesforce does not support installing full certificate chains (i.e., root + intermediate certs). Only the main certificate.pem file is supported, and it's expected to be leaf-only. As a result, some browsers or org-level security tools may flag certificates as incomplete or untrusted because they can’t verify the full chain when hitting a Salesforce-hosted domain (e.g., *.force.com, *.live.siteforce.com).	⚠️ Corporate networks with strict SSL validation might show warnings. ⚠️ Browsers may display untrusted certs if intermediate roots are missing and cannot be inferred. ✅ Most modern systems will still work, since browsers typically cache or infer the root chain.	We have not encountered issues, however some browsers or organizational policies may flag security warnings. Workaround: Use CDNs like CloudFront or Cloudflare to terminate SSL externally, where you can install full chains.