Customer Self-Service Portal

The problem

Your B2B customers cannot see their own data. They email a customer service representative to ask where an order is, phone in a reorder that someone retypes into a sales order, and open a ticket to ask what price they should be paying under their trade agreement. Every one of those interactions consumes a person on your side, and none of them is a use case Microsoft licenses an external buyer to perform inside Dynamics 365 Finance & Operations directly. Giving a customer a licensed F&O seat is neither affordable nor appropriate — they would land in a back-office UI built for your staff.

The result is a service desk acting as a human API over the ERP. Order status questions arrive by email. Reorders arrive as PDFs and spreadsheets that get rekeyed, with the transcription errors that implies. Returns start as a phone call and only become a return order days later. Meanwhile the data the customer wants — the sales order, the packing slip, the shipment, the invoice, the trade agreement price — is already sitting in F&O tables, correct and current.

What ECOSIRE builds

ECOSIRE builds a customer-facing web portal and the Dynamics 365 Finance & Operations extension layer that feeds it. This is a build-to-order engagement: nothing here is a shrink-wrapped download. We scope against your entity model, your order-to-cash configuration and your security posture, then build, deploy and hand over the source.

The F&O extension layer

All ERP-side code ships as X++ extension models — event handlers, CoC (chain of command) classes, table and form extensions, and extended data entities. There is no overlayering; the model is built against your platform version and deploys through your own LCS/sandbox pipeline as a deployable package.

The portal never talks to F&O tables directly. We build or extend data entities exposed over OData, plus custom service groups (SysEntryPointAttribute-decorated services) for the operations that are transactional rather than CRUD — placing an order, requesting a return, confirming a delivery address. Authentication is service-to-service via a registered Entra ID application with a dedicated F&O service user, and every call is scoped to the calling customer account. The portal identity is separate from the ERP identity: portal users are contacts mapped to a CustTable account, not licensed F&O users.

Reorder and order placement

The portal renders the customer's purchasable catalogue from released products with the customer's own item numbers where you maintain external item descriptions. Pricing is resolved through the trade agreement engine rather than reimplemented — we call the F&O price/discount resolution so the number the customer sees is the number the sales order will carry, including customer-specific price lists, quantity breaks and multiline discounts. Orders are created as SalesTable/SalesLine records through a service, honouring your order pools, delivery modes and site/warehouse defaults, and can be routed into a workflow for credit or approval review before confirmation.

Tracking, documents and returns

Order tracking reads confirmed sales orders, packing slips and shipments, so the customer sees the same picture your CSR sees. Where you run advanced warehousing, shipment and load status flows through so the portal reflects wave and load progress rather than a static "processing" label. Invoices and packing slips are surfaced as documents from print management / attachments. Returns are raised as return orders against the original invoiced line, with the return reason code, disposition expectations and RMA number issued back to the customer immediately rather than after a phone queue.

Data flow and operations

Synchronous reads use OData with server-side paging; heavy or bulk operations use the data management framework and the batch framework so a large catalogue refresh or a nightly document sync does not sit on an interactive request. Where you already run Dual-write or the Power Platform, we can source portal identity and case data from Dataverse instead of duplicating it — that is a scoping decision, not an assumption.

Who this is for

Distributors, manufacturers and wholesalers running Dynamics 365 Finance & Operations with a repeat B2B customer base: customers who order the same items again and again, hold negotiated pricing, and generate a steady volume of "where is it / what does it cost / can I send it back" contacts. It suits organisations with multiple legal entities, since the portal resolves the correct entity per customer account.

It is a poor fit for pure consumer e-commerce with no account relationship, and for organisations that have not yet stabilised their trade agreement configuration — the portal will faithfully display whatever pricing your ERP resolves.

How delivery works

1. Scoping call. We walk your order-to-cash setup, entity structure, product master, trade agreement usage, warehousing configuration and identity requirements, and agree the portal's exact scope. 2. Fixed quote. You receive a written scope and a fixed price before any build starts. Changes after that point are quoted as change requests, not absorbed silently. 3. Build. Typically 2–4 weeks depending on scope. The X++ model, the entities/services and the portal application are built against a copy of your configuration. 4. Install in test. We deploy the deployable package to your sandbox through your LCS pipeline, configure it with you, and run through the agreed scenarios with your team. 5. Production. After your sign-off, the same package is promoted to production through your normal release process. We do not push code into your production environment outside your controls. 6. Support. A defined post-go-live support window is included for defects in what we built, with the source code handed to you so you are never dependent on us to continue.