Skip to content
Van Oosten Advies B.V.

Reference · Our own Business Central app

The website asks, Business Central answers

A customer who requests a quote on a website wants to see it again without phoning. CustomerGate 365 is the Business Central app that makes that connection: requests arrive on a worklist for inside sales, and customers sign in to a portal to see their quotes, orders, shipments and documents. One app for every company; what differs per customer is configuration, not code.

At a glance

Client
Our own product, published as Van Oosten Software
What
CustomerGate 365, an app for Microsoft Dynamics 365 Business Central
My role
Design, build, documentation and the publication on AppSource
Timeline
Built in 2026
Status
Version 1.0.39.0, on AppSource
The Web Requests list in Business Central with fifteen requests from the website, their status, who is handling them and the screening result

The journey of one request

  1. On the website

    A visitor puts items in a request and sends it. Business Central takes it in, or names the reason why not.

  2. In the work queue

    Inside sales sees the request with its lines, screened for duplicates and spam, and picks it up.

  3. One button

    Process Request turns it into a sales quote, with the customer, the lines and the visitor's own reference.

  4. In the portal

    The customer signs in with a code, sees the quote and accepts it. The acceptance is in Business Central straight away.

Where it started

Customers phone about their order. Where is the quote, has the shipment left, can the invoice be sent once more? Those are questions whose answers already exist, in Business Central, but not anywhere the customer can look.

At the front it is the same story: a form on the website lands in a mailbox, and somebody retypes it into a quote. That takes time and it goes wrong now and then. So the plan was one chain, from the question on the website to the document in the portal, with Business Central as the only source.

What was built in Business Central

CustomerGate 365 is an app in Business Central, and that is where the work happens. These are the screens of inside sales and of the administrator, from a sandbox with Microsoft's demo data: the same company, the same customer and the same request, from start to finish.

For inside sales

Every request on one worklist

A request from the website appears in Business Central with a number of its own, its status and who sent it. The app screens every request for duplicates and unwanted traffic, but decides nothing: nothing moves on by itself and nothing disappears by itself.

The Web Requests list with fifteen requests: number, status, company, contact person, who is handling them and the screening result, with WEB000035 marked Suspect with a score of 30

  1. The actions of inside sales: process, link a customer, start processing, reject or mark as spam.

  2. Who is handling the request. Everyone can see it, so no one picks it up twice.

  3. The screening: a judgement with a score. Suspect means: take a good look, not: throw it away.

The card of web request WEB000029 with status Converted, the Process Request, Link Customer and Show Sales Document actions, and the details of the requester Adatum Corporation

Everything the website sent along

The card shows what the visitor filled in: company, contact person, address, their own reference and the item lines. Link Customer ties the request to an existing customer; inside sales does that, not the website. Once the request is converted, Show Sales Document opens the quote that came out of it.

One button, and it is a quote

Process Request turns it into a sales quote for the linked customer: quote 1020, with the twelve tables and twenty-four chairs from the request. The request itself goes to Converted. Nothing is typed over, and nothing falls through the cracks.

Sales quote 1020 for Adatum Corporation with external document number OFFERTE WEEK 39, two item lines and comment lines that refer to web request WEB000029

  1. The reference the visitor chose, as the external document number.

  2. The items and quantities from the request; Business Central prices them as it does any quote.

  3. A line with the request number, so later it is clear where the quote came from.

Access through inside sales

Whoever asks for a portal account on the website lands in a list in Business Central. Inside sales selects the customer and approves, and on approval the app asks which role the user gets. Only then does the portal user exist.

The Account Requests list with three requests for a portal account; ACC000022 from Adatum Corporation is already linked to customer 10000

  1. Select Customer and Approve: the decision lies with inside sales, request by request.

  2. The customer inside sales linked, beside the customer number the requester stated.

For the catalog

Business Central decides what is on the website

With a few rules inside sales decides which items the website gets to see: a range of item numbers, an item category, or everything without a description. The first rule that fits decides. Every item then shows which rule that was, so no one has to guess why something is or is not online.

The Web Publication Rules list with four rules: item numbers 19* published, and items without a description, the DIVERSEN category and the *-W packages excluded
The Items on the Website list showing for every item whether it is online and why, such as Rule 10 (its description in Dutch: "Artikelen van de 19-reeks staan op de website"), or excluded on the item

For the administrator

Set up in a few steps

An assisted setup walks through the configuration. It checks for itself whether iFacto Steel 365 is in the environment and switches the steel module on or off. The website signs in with a registration of its own in Microsoft Entra ID: Business Central only gets the client ID, the secret stays with the website.

The Set Up CustomerGate 365 guide at the Steel 365 step, with the module off because Steel 365 is not in this environment
The Connect the Website step, with fields for the two client IDs and the explanation that the client secret stays with the website

The app checks itself

One screen says whether everything works: the environment, the licence, the jobs, the connections and the mail, each with a verdict. Where a line knows a remedy, such as repairing the permissions or publishing the web services, Fix carries it out. Without that button nothing is repaired.

CustomerGate Diagnostics with 0 failed and 0 warnings, the Test Connection and Fix actions, and lines for the environment, the licence and the app version

  1. The verdict at a glance: nothing failed and no warnings.

  2. The report holds only counts and states, so it can go to support without a second thought.

  3. Fix carries out what a line suggests, and only when someone clicks it.

Any website, the same app

CustomerGate 365 does not deliver a website. It delivers the agreement a website talks to: web services in Business Central for the catalog, the requests and the portal, laid down in a contract that every build checks.

So which website that is does not matter: a new site, an existing web shop or a portal in the customer's house style. Beside this is the message with which the demo website sent in request WEB000029, and below it that demo website itself: one example of many.

The web services for website builders
The website's message

The website sends

voaRequests_CreateQuoteRequest(payload)

{
  "companyName": "Adatum Corporation",
  "contactName": "Loek Walravens",
  "email": "inkoop@adatum-demo.com",
  "customerReference": "Offerte week 39",
  "privacyAccepted": true,
  "privacyConsentVersion": "2026-09",
  "quoteRequestLines": [
    { "itemNo": "1896-S", "quantity": 12 },
    { "itemNo": "1900-S", "quantity": 24 }
  ]
}

Business Central answers

{ "number": "WEB000029" }
The customer portal of the demo website with quote 1020 from request WEB000029 and buttons to accept or decline it

How I went about it

  1. One app, settings per customer

    No custom code per customer. Everything that differs per company, such as the website's registrations, the document source and the inside sales language, is a setting. What works for one customer works for the next.

  2. The interface as an agreement

    Every web service, every key and every error code is fixed in a contract file that is generated from the code and checked in every build. Whoever builds the website gets a TypeScript client with it.

  3. Two countries in every build

    The Netherlands and Belgium differ exactly where this app works: VAT numbers, addresses, creating customers. So every build runs every test in both countries, against Business Central 28 and 29.

  4. Steel without a dependency

    For companies with iFacto Steel 365 a module switches itself on: profiles, grades, three quantities per line and the document archive. Without Steel 365 everything works with the standard Business Central fields.

What the app does not know, and does not keep

A portal that shows customer data has to be explainable. These are the rules, fixed in the code.

The customer number does not travel

The website does not know which customer number belongs to a visitor, and cannot ask for it either. The link between an e-mail address and a customer is made in Business Central, by inside sales.

Signing in without a password

The portal sends a one-time code by e-mail. So there is no password to be stolen, reused or forgotten.

Per role, what someone may see

A portal user is a buyer or a reader, tied to one customer. They see that customer's documents and nothing beyond; Business Central enforces that, not the website.

Personal data expires

Requests carry a retention period. A job clears out whatever is past it, and the setup page shows whether that job is really running and how much is waiting.

See it, take it, erase it

Per e-mail address everything can be exported or erased, the GDPR rights that matter in practice. Every field is classified as well, so Business Central itself knows what is personal data.

Documents from the source

The PDFs come from the reports Business Central already uses, or from the industry software's document archive where there is one. Nothing is stored separately that could start to differ.

The Privacy group on CustomerGate Setup: a retention period of 365 days, the status of the cleanup job, the last cleanup run and zero cleanup errors
This is how it looks on the setup page: the retention period, whether the cleanup job is running, when it last ran and whether that went well.

The result

CustomerGate 365 is on AppSource at version 1.0.39.0, and builds and tests cleanly against Business Central 28 and 29. The app is English with four translations: Dutch for the Netherlands and Belgium, and French for Belgium and France. The setup guide, the web service reference, the licence terms and the privacy statement are on this site.

For AppSource it has an object range of its own from Microsoft, telemetry in Azure, a signature from Azure Artifact Signing, and its offer in Partner Center.

More about the app itself on the product page

In figures

countries in every build: Belgium and the Netherlands, with every test in both
2
translations besides English: Dutch and French, for Belgium, the Netherlands and France
4
the Business Central versions the app is built against
28 · 29
warnings from the four code analyzers: a single warning fails the build
0

Technology

Standard Business Central and standard Microsoft sign-in. No server in between, no user database of our own.

  • AL for Business Central
  • Web services (OData)
  • Microsoft Entra ID
  • Job queue
  • AppSourceCop
  • AL-Go for GitHub
  • Next.js for the portal

The services behind this reference

Do you want your customers to see online what Business Central holds?

Tell me what your customers phone about today. I will tell you honestly whether a portal pays for itself, and what it takes to set up.

Book an introductory call(opens in new tab)Send a message