Skip to content
Van Oosten Advies B.V.

Last updated: September 21, 2026

Permission Gaps in CustomerGate 365

CustomerGate Permission Gaps puts what CustomerGate 365 writes into the permission sets next to what this environment actually grants, per object, and by default only where the two differ. The screen writes nothing. It exists because a missing permission announces itself as a 403 on one call, and the question after that is always the same: what should be there, and what is there?

What a gap is

The definition is read from the app itself, so there is no second list that could drift. Every line shows:

Permission Set
Which set or which account this line is about.
Object Type, Object
A table, codeunit, page, report or permission set, with its number and, where this environment knows it, its name.
Expected
What CustomerGate 365 writes here. An upper-case letter is a direct permission, a lower-case letter an indirect one: R read, I insert, M modify, X execute.
Granted
What is actually granted in this environment, in the same notation.
Verdict, Explanation
Failed, Warning or Passed, with one sentence on what the line means and what to do about it.

Show All removes the filter and also lists the lines that are in order and the lines skipped because the app that owns the object is not installed here. Only Differences puts the filter back. Showing two hundred green lines to hide three red ones among them is the same as showing nothing.

It worked yesterday and gives a 403 today

A line that differs almost always means the tenant permission set was written by an older version of the app. Those sets cover objects of other publishers, so the app writes them as data rather than as AL objects. An update brings new lines with it, but a set that already exists is only brought up to date when somebody chooses Repair Permissions. Until then the website works everywhere except at the one point that was added, and that is precisely the picture of a call that worked yesterday.

Repair Permissions

Repair Permissions creates or corrects the tenant permission sets and assigns them to the applications of the website and the synchronization. The same action sits on CustomerGate Setup, with the same question in front of it.

  • Lines that someone added by hand are kept. That is the quickest fix after a 403; let us know afterwards, so the line goes into the app.
  • No line is ever removed automatically.
  • A line for an app that is not installed here is skipped and reported as such.
  • Only somebody with the SUPER permission set can repair. Without SUPER nothing happens and the status lines on the setup page stay as they are.
  • Business Central applies changed rights only after a few minutes. Close the screen, wait a moment and look again.
  • The security filter on the document archive is set to exactly the categories on Archive Categories. So choose Repair Permissions again after changing those categories.

What the two Entra applications get

Repairing registers both Entra applications, from Website Client ID and Synchronization Client ID on the setup page, and assigns, for all companies:

AccountPermission sets
WebsiteVOA WEB API, VOA WEB PORTAL, VOA WEB BASELINE, VOA WEB CONTRACT, VOA CG EXECUTE and VOA CG MAIL; plus VOA CG S365 ARCHIVE where the document archive is installed, VOA CG DOCUMENTS with Portal Documents from Reports, and CDC BASIC where Continia is installed
SynchronizationVOA WEB SYNC; plus VOA CG S365 SYNC with Steel 365
Inside salesVOA Web Inside Sales, assigned by an administrator. The job queue user needs it too, plus the usual rights to send e-mail
AdministratorsVOA Web Admin, assigned by an administrator

The website account never gets D365 BASIC, and that is not a detail: that set gives read access to customers, contacts, sales documents and margins, while this account is reachable from the open internet. VOA WEB BASELINE is the floor a web service session needs. If D365 BASIC is assigned anyway, the connection test says so.

Code that runs for everyone

Part of the app runs under people who carry none of CustomerGate's permission sets: a warehouse employee posting a shipment, a buyer changing an item, somebody who has never heard of the website. That code therefore declares its own permissions on its own tables, so that a posting or an item change never falls over on a table that has nothing to do with that user's screen. Those permissions are indirect: the tables cannot be read through an API page or an OData query with them, only code that carries the direct permission itself can touch them.

A 403 on an object the app does not know

The error from Business Central names the object that is missing. Then do this:

  1. Check on Permission Gaps whether the object is already listed with a difference. If it is, choose Repair Permissions and try again after a few minutes.
  2. If it is not listed, add the line to the tenant permission set by hand. Repairing keeps it afterwards.
  3. Let us know, so the line goes into the app and every environment gets it.

A report or a layout of your own often reads more tables than VOA CG DOCUMENTS covers. A PDF that is not available without any error appearing is almost always that: a report runs with the permissions of the account, and the request for a PDF simply comes back empty when a permission is missing.

Related help