Toshfa OptimaX
Workflow Blueprint

Ten findings, before the detail

• 01Toshfa OptimaX is one platform on a single shared database — a core API drives four purpose-built operational interfaces (Toshfa OptimaX Core, CRM, TPA Hub, Vision 360), and a dedicated middleware API drives four customer self-service channels (E-commerce, Mobile App, Client Portal, Member Portal), all reading and writing the same underlying data.
• 02The core lifecycle (Quote → Policy → Endorsement → Claims → Finance) is deeply implemented, with Endorsement a mature, extensive engine spanning member addition, deletion, upgrade, downgrade, correction, nil endorsements, and border-to-Iqama conversion — the last two auto-approved, bypassing the shared approval step.
• 03Renewal is not a separate engine — a renewed policy carries forward a direct link to its prior term.
• 04A single, shared, role-gated approval mechanism — not a per-module bolt-on — backs decisioning across Quote, Policy, Finance and other transaction types.
• 05The CRM interface is real and substantial: a genuine lead-to-quote sales pipeline, an opportunity pipeline, Customer 360, a ticket support queue, and WhatsApp conversational journeys, confirmed directly in the underlying system.
• 06The TPA Hub interface is the most thoroughly evidenced of the four — a scheduled synchronization pipeline with a 9-module operator console.
• 07The Vision 360 interface is real and more built than its own specification document describes — three executive BI dashboards plus a self-service report-builder layer.
• 08Finance is a genuine double-entry ledger, with reversal support, a collections workflow, and bank-statement reconciliation.
• 09Role-based access control and platform notifications (WhatsApp, email, SMS) and versioned documents are real and implemented across the ecosystem.
• 10External integrations spanning national identity/regulatory services, payments, and TPA/aggregator connections are documented and confirmed (Sections 16–18).

One platform, four user interfaces, one insurance lifecycle

Toshfa OptimaX is a full insurance-lifecycle platform for insurers and TPAs, covering everything from the first sales conversation through to claims payment and executive reporting. It runs on one shared database, presented through four purpose-built operational interfaces: the Toshfa OptimaX Core interface carries a policy from quote through claims and finance; CRM runs the sales and customer-engagement side of the business; TPA HUB pushes Policy, Plan/Class and Member data out from Toshfa OptimaX to a Third-Party Administrator's claims-adjudication system, keeping the two in sync automatically; and VISION 360 gives management a single analytical view across quotations, policies and claims.

Because every interface shares the same underlying platform, information entered once — a lead in CRM, a member change in an endorsement, a TPA sync update — is immediately visible everywhere else it matters, with no duplicate entry and no reconciliation between systems.

Alongside these four operational interfaces, a set of CUSTOMER CHANNELS — E-commerce, Mobile App, Client Portal and Member Portal — gives online customers, corporate clients and individual members direct self-service access. These channels connect through a dedicated middleware API into the same shared database, so a purchase, endorsement request or claim submitted through a channel lands in the same records the operational interfaces work from.

One shared database, four operational interfaces

All four operational interfaces sit on the same shared foundation. Nothing about the underlying data or business logic is duplicated between them — each interface simply presents the part of the platform relevant to the person using it. The Mobile App and Customer Channels blocks below the shared core (E-commerce, Client Portal, Member Portal) read and write the same database too, through a dedicated middleware API rather than the core API — details further down.

Customer self-service channels

These channels do not carry their own copy of the data — every purchase, endorsement request or claim submitted through one of them is written straight into the same records the four operational interfaces above work from, just reached through a middleware API rather than the core API.

Customer to analytics, in eight stages

Every interface plugs into one customer journey. The diagram shows which interface primarily owns each stage — Toshfa OptimaX Core owns the transactional spine from Quote through Finance, CRM owns the customer relationship that starts the journey, TPA Hub sits alongside Policy/Endorsement keeping a TPA in sync, and Vision 360 observes the whole journey from the outside.

Lead → Opportunity → Customer, with support ticketing alongside

Confirmed directly against the CRM interface itself — this is a fully working set of workflows, not a placeholder.

From census to activated policy

A quote carries its own status, decision status and approval status as it moves through the process, and premium calculation is handled distinctly for each business segment. Assumption: a census upload appears to feed directly into the quote rather than passing through a separate, formal request-for-quote stage; confirm this matches the intended sales design.

For the Individual segment, a customer can also complete this journey directly through the E-commerce channel or the Mobile App — both connect through the middleware API into this same quote-to-policy engine, rather than a separate one.

A quote can also originate from an aggregator (Bcare, Tameeni, Damin — Section 17): the aggregator sends the quotation request in, Toshfa OptimaX returns a quote, and on the customer's acceptance the aggregator sends the policy request back into this same conversion path.

One record, carrying its own history forward

A policy carries its own status and a running renewal count, and keeps a direct link back to the term it replaces when renewed — a policy's history is modeled as a self-referencing chain, not as a separate lifecycle record.

Eight transaction types, most sharing one approval path

An extensive, mature engine confirms support for every major endorsement transaction type — richer than the endorsement types previously documented for client review. Two types — Nil Endorsement and Border-to-Iqama conversion — are auto-approved, bypassing the shared approval step entirely.

Corporate clients can also submit these same requests — Member Addition, Deletion, Upgrade, Downgrade, Nil Endorsement and Border-to-Iqama conversion — directly through the Client Portal, which routes through the middleware API into this same approval path (or straight to Policy for the two auto-approved types) rather than a Client-Portal-specific one.

An aggregator (Bcare, Tameeni, Damin — Section 17) can also submit an endorsement request through the same integration channel it uses for quotes and policies.

Adjudicated claims from the TPA, staged, fraud-scored, then posted

For this client the primary claims intake path runs through the TPA (GlobeMed): the TPA sends already-adjudicated claims database-to-database into a staging area, where the data is validated before being loaded into Toshfa OptimaX. As claims load, an automated fraud-detection engine scores each one; the claims department sees the resulting cleared batch and can post it directly, generating a credit note that goes to Finance for the provider payment. Claim batches can also be raised internally rather than received from a TPA (Section 11).

An individual insured member can also submit a reimbursement claim request directly through the Member Portal, and use the same portal to check their policy, benefit, coverage and network details — again routed through the middleware API into these same claim and policy records.

Renewal reuses the Quote-to-Policy path by design

Renewal is fully implemented as a deliberate design choice rather than a separate engine: a renewal is executed as a new policy record linked directly to its predecessor (Section 06), which re-enters the same Quote-to-Policy path (Section 05) for the new term. This keeps renewal behavior — pricing, decisioning, and approval — consistent with new business rather than duplicating that logic in a second workflow.

For the SME segment, renewal is also available self-service through the E-commerce and Mobile App channels, rather than only through Toshfa OptimaX Core.

A real double-entry ledger, not just invoicing

Every financial entry is tracked as a debit and credit pair, with a clear draft/posted status. Reversal is a supported, first-class action — not a manual workaround. A broad set of financial workflows covers payments, receipts, debit/credit notes, and a genuine collections process.

A scheduled sync pipeline, confirmed end to end

Every stage below is corroborated three separate ways: the underlying system, the platform's own process documentation, and the actual operator console screens — all three sources agree, with no gaps found.

Three categories of data are pushed out from Toshfa OptimaX to the TPA: Policy Data, Plan/Class Data, and Member Data. The pipeline below is how that push happens — contract and plan/class detail go out first, member-level endorsements follow and are confirmed and committed on both sides before the cycle repeats.

TPA Hub is the monitoring and operations hub for these Policy, Technical Sheet, Endorsement and Member integrations. From the console, the TPA operations team can reprocess and retry any failed transaction, edit a transaction before retrying it, track and manage integration status end to end, download the underlying XML transaction logs, view a performance dashboard, and pull reports on TPA integration activity.

The relationship runs in both directions: Policy, Plan/Class and Member data are pushed out to the TPA as shown below, while claim batches raised by the TPA are received back in through TPA Hub and land directly in the Claims workflow (Section 08).

The four sync stages carry a defined set of fields out to the TPA. The table below is the actual field mapping used for one live integration (GlobeMed) as a concrete example — the same four-stage pipeline applies to any TPA, with its own field mapping configured per integration. Fields without a description are self-explanatory identifiers or values not yet documented.

Executive dashboards, plus a self-service reporting layer

Three executive Command Center dashboards — Quotation, Policy, and Claims — are confirmed live end to end. Alongside them, a separate self-service reporting layer provides genuine report building, saving, and sharing — more built than its own specification document describes.

Roles inferred from access scoping and workflow-stage ownership

The platform's role-based access model is real and confirmed — permissions are scoped by module, with access controllable down to the individual screen level. The specific role list below, however, is inferred from which part of the platform each workflow stage belongs to — it is not a confirmed, client-approved list of role names and should be validated with the product team before being presented as authoritative.

One shared mechanism, reused everywhere

A single, shared decision-routing mechanism — not a separate one for each area — moves any transaction through an ordered set of role-gated approval stages until it reaches a final, approved state. Quote, Policy, Endorsement and Finance transactions all use this same mechanism rather than each having bespoke approval logic.

Versioned documents, multi-channel messaging

Confirmed national and partner services

Recovered from the platform's own reviewed integrations documentation (its confirmed sections only — the source document itself flags a later section as suggested/unverified, which is excluded here).

A two-way exchange with each aggregator

Bcare, Tameeni and Damin are insurance aggregators that bring their own customers to Toshfa OptimaX for a quote. This is substantial enough to warrant its own section: the exchange runs in both directions on the same channel for each aggregator — a quotation request comes in, a quote goes back, a policy request comes in on the customer's acceptance, and endorsement requests follow once the policy is in force.

Bcare

Insurance aggregator — quotation, policy issuance and endorsement exchange.

Tameeni

Insurance aggregator — quotation, policy issuance and endorsement exchange.

Damin

Insurance aggregator — quotation, policy issuance and endorsement exchange.

Visitor policy issuance through the MOFA integration

Beyond standard resident policies, the platform issues a set of visitor-specific policy segments through its existing MOFA (Ministry of Foreign Affairs) integration — covering people in the country on a temporary or visitor basis rather than a standard residency (Iqama).

Ministry of Foreign Affairs (MOFA)

The national integration these four visitor policy segments are issued through — the same MOFA/Masdar/Elm service referenced in Section 16.

Every workflow found, in one table

Which interface touches which lifecycle stage

The whole ecosystem, in one picture

A customer's journey starts in CRM, an Aggregator, or the Customer Channels / Mobile App self-service path — all three feeding a Quote (with Aggregators and Customer Channels able to submit an Endorsement directly too) — or arrives as a Visitor (MOFA) policy segment straight into Policy. From there it runs the transactional spine through Toshfa OptimaX Core, is kept in sync with TPA Hub and CHI, passes claims through fraud-detection scoring on the way to Finance, and is observed end to end by Vision 360.