Architecture

This section outlines the high-level architecture of MiraBridge Phone, including system components, boot sequence, and key design principles.

System Components

MiraBridge Phone is composed of the following key components:

1. MiraBridge API (Backend Service)

  • Handles requests to the /api/v1/deployment/:deploymentId/init endpoint.
  • Returns pre-boot loader code and configuration.
  • Manages:
    • Session creation and license seat validation
    • Delivery of dynamic CRM logic
    • Diagnostics and telemetry (if enabled)

2. MiraBridge Loader (Pre-Boot Code)

  • Served by the MiraBridge API and loaded by the CRM.
  • Initializes core MiraBridge logic and loads required SDKs.
  • Handles:
    • Establishing session context
    • Displaying the Genesys iframe
    • Preloading CRM-specific code

3. Genesys Cloud iFrame

  • Embedded within the CRM interface.
  • Renders the Genesys softphone using the Embeddable Framework.
  • Loads the static framework.js file hosted in Genesys Cloud.
  • Initializes Genesys communication features (calls, chat, etc).

4. CRM Interoperability Layer

  • Loaded after successful login to Genesys Cloud.
  • Binds Genesys events to CRM workflows (e.g. screen pop, case creation).
  • Operates entirely client-side under agent permissions.

System Architecture Overview

MiraBridge Phone operates on a distributed architecture that maximizes security and performance while minimizing server-side dependencies. The system is designed with three core principles:

  1. Agent-Centric Processing: All sensitive operations occur within the agent’s browser
  2. Minimal Server Dependencies: The MiraBridge API serves only configuration and licensing
  3. Standards-Based Integration: Built on established frameworks (Genesys Embeddable Framework, CRM SDKs)

Key Components

  • MiraBridge API: Lightweight service for deployment configuration and license management
  • Browser Loader: Client-side orchestration layer that initializes all components
  • Genesys Cloud iFrame: Official Genesys widget providing telephony functionality
  • CRM Interop Layer: Platform-specific integration logic for each supported CRM

Boot Sequence

The initialization process follows a carefully orchestrated sequence to ensure security and reliability:

  1. CRM Loads MiraBridge API Widget
    The CRM platform embeds a widget URL pointing to the MiraBridge API. The API validates the deployment and returns loader code with environment-specific configuration.

  2. Loader Initialization
    The client-side loader establishes session context, validates parameters, loads required SDKs, and prepares the environment for the Genesys widget.

  3. Genesys Cloud Authentication
    The agent authenticates with Genesys Cloud through the official OAuth flow within the embedded iframe. No credentials pass through MiraBridge systems.

  4. License Validation
    After successful authentication, the loader contacts the MiraBridge API to validate deployment permissions and consume an available license seat.

  5. CRM Integration Activation
    With license validation complete, CRM-specific interoperability features are activated, connecting Genesys events to CRM workflows and data.

Detailed Boot Sequence Diagram

The diagram below illustrates the full initialization and connection flow of MiraBridge Phone:

sequenceDiagram
    participant CRM as CRM Platform
    participant MiraBridge as MiraBridge API
    participant Loader as MiraBridge Loader
    participant Genesys as Genesys Cloud
    participant Framework as framework.js
    participant SDK as CRM Interop Layer

    CRM->>MiraBridge: GET /api/v1/deployment/{deploymentId}/init
    MiraBridge-->>CRM: Loader JS (Preboot)
    CRM->>Loader: Execute loader
    Loader->>Genesys: Load Genesys widget in iframe
    CRM->>Genesys: Agent logs in
    Genesys->>CRM: Loads framework.js
    Framework->>MiraBridge: Validate license
    MiraBridge-->>Framework: Seat validated ✅
    Framework->>SDK: Initialize CRM interoperability
    SDK-->>Framework: CRM hooks & automation ready
    Framework-->>CRM: Genesys + CRM fully integrated

Runtime Data Flow

The following diagram illustrates how data flows between systems once the widget is running:

graph TD
    CRM[CRM Platform] -->|"Loads Widget"| MiraBridgeAPI[MiraBridge API]
    MiraBridgeAPI -->|"Returns Loader + Config"| CRM

    CRM -->|"Renders"| Loader[MiraBridge Loader]
    Loader -->|"iFrame Embed"| GenesysCloud[Genesys Cloud Widget]
    GenesysCloud -->|"OAuth Token Request"| GenesysAuth[Genesys Cloud OAuth]

    GenesysCloud -->|"Render UI"| Agent[Agent Interface]

    Agent -->|"Logs In"| GenesysCloud
    GenesysCloud -->|"Session Starts"| Framework[framework.js]

    Framework -->|"Validate License"| MiraBridgeAPI
    MiraBridgeAPI -->|"OK / Reject"| Framework

    Framework -->|"CRM Interop Events"| CRMInterop[CRM Interop Layer]
    CRMInterop -->|"Update CRM (screen pops, tasks, cases)"| CRM
    CRM -->|"User Actions"| GenesysCloud
    GenesysCloud -->|"Interaction Events"| CRMInterop

💡 Key Concepts:

  • The CRM only interacts with Genesys through the embedded iframe and via the interoperability SDK after login.
  • MiraBridge API handles licensing and bootstrapping but never receives customer or agent PII.
  • Data flows are unidirectional and sandboxed inside the browser.

Performance and Scalability

Performance Characteristics

  • Initial Load Time: 2-5 seconds typical (depends on network and CRM platform)
  • Memory Footprint: ~50-100MB additional browser memory usage
  • Network Requirements: Minimal ongoing bandwidth (primarily WebRTC for voice)
  • CPU Usage: Low impact, leverages browser optimizations

Scalability Considerations

License-Based Scaling:

  • Each concurrent user consumes one license
  • No per-transaction or usage-based limits
  • Automatic license release on session termination

Infrastructure Scaling:

  • MiraBridge API is stateless and horizontally scalable
  • No persistent storage requirements for user sessions
  • CDN-distributed static assets for optimal global performance

Enterprise Deployment:

  • Supports thousands of concurrent users per deployment
  • Multi-region deployment capabilities
  • High availability and disaster recovery options

Integration Patterns

Supported CRM Integration Methods

  1. Channel Integration Framework (CIF v1/v2) - Microsoft Dynamics 365
    • Native integration with full Dynamics ecosystem
    • Supports unified interface and customer service applications
    • Built-in presence sync and screen pop capabilities
  2. Lightning Component Framework - Salesforce (Coming Soon)
    • Lightning-native components for optimal performance
    • Integrated with Salesforce Service Cloud features
    • Support for custom Lightning applications
  3. iframe Embedding - Universal
    • Standards-based integration for any web platform
    • Configurable security policies and dimensions
    • Custom event handling for bespoke CRM solutions

Data Synchronization Patterns

  • Real-time Screen Pops: Automatic contact/case retrieval based on interaction context
  • Activity Logging: Automatic creation of interaction records in CRM
  • Presence Sync: Agent status synchronization between systems
  • Custom Workflows: Configurable automation triggers and actions

Design Principles

  • Agent-Scoped Execution
    All CRM logic runs locally in the browser under agent permissions.

  • Session-Based Licensing
    Seats are consumed at login and released on logout (or auto-expire after 60s on disconnect).

  • Thin, Event-Driven API
    The MiraBridge API is lightweight and stateless between sessions, used only to bootstrap the widget and track usage.

Responsibilities Breakdown

Component Role
MiraBridge API Serves loader code, handles licensing, returns deployment config
MiraBridge Loader Bootstraps widget and SDKs, renders Genesys iframe
Genesys Cloud iFrame Displays Genesys UI, manages communication and authentication
CRM Interop Layer Connects Genesys events to CRM workflows after login