Dynamics 365 F&O

Finance and Operations/AX User Forum
1

Hello everyone,

I’m studying the licensing model for Dynamics 365 Finance & Operations and I have a question about the “up to 15 custom tables” available for Team Members users.

I’d like to better understand the intended purpose of this feature in practice.

Is it permitted to create a workspace with an interface based on three custom tables, where users with a Team Members license enter business process information (for example, as a draft), and then an integration using Dynamics 365 Operations – Order Lines writes the data to the eligible tables defined in the licensing documentation (for example, SalesLine)?

Or is the up to 15 custom tables entitlement intended only for specific scenarios and not for this type of use case?

If possible, I would appreciate an explanation with practical examples of when this entitlement can be used and what its limitations are.

Thank you!

2

Hi @Maria_Alice_Santana

Quick clarification first: the “15 custom tables” limit is a Dataverse entitlement, not an F&O one. It lets a Team Member app module have up to 15 extra tables (custom or standard Dataverse), where Team Members get full CRUD. It has nothing to do with F&O tables like SalesLine, those live in a different database and are governed by separate rules (the pre-approved light-duty scenarios: read data, approvals, timesheets, expenses, etc.).

Your scenario, Team Members entering draft data into a few custom Dataverse tables, with an integration then pushing that data into SalesLine, is fine and is actually pretty close to how Microsoft intends this to work. The important part is that the Team Member never writes to SalesLine directly. Only the integration (a flow, dual-write, or service account) does that, and that integration identity needs its own proper F&O license; the Team Member’s license doesn’t cover it.

A few things to keep in mind:

  • The 15-table cap is shared across the whole app module, not per workspace.
  • The custom tables should map to an approved use case (per Appendix C), not just any process you want to build.
  • Enforcement isn’t really policed by the system today; it’s more of an audit/compliance thing.

So yes - technically doable, and licensing-wise it’s the right pattern, as long as the write-back integration carries its own valid license.

3

Thank you for your response.

That’s exactly what I’m planning to do: create a custom table where Team Member users can enter the information. However, the actual record creation will be performed by a service account with the appropriate license for the transaction.

In this scenario, can I create a workspace where the user opens the form, fills in the required information, and then the integration, using the appropriately licensed service account, creates the record?

4

Hi @Maria_Alice_Santana

Yes, that setup works, a couple of things to keep in mind on the F&O side:

F&O checks licenses by menu item/role, not by table. So as long as the Team Member’s role only ever touches your custom table/form, they’re fine; what matters is what they access, not what happens downstream.

Key point: the actual write to the licensed table must happen under a different identity, not just different code. If the same interactive session that filled the form also creates the SalesLine record, that’s still the Team Member doing the privileged action, even if it’s “the integration” doing it in code. It needs to run in a separate execution context.

The usual way to do this:

  • Team Member fills the form → saves to your custom table, just flips a status (e.g. “Ready”).
  • A batch job or external integration (Power Automate, Logic App, Azure Function, etc.) running under a properly licensed service/application account picks up “Ready” records and creates the actual SalesLine.

So: draft in custom table = Team Member’s job. Actual record creation = separately licensed identity’s job. That split is what makes it compliant, and it’s a pretty standard pattern in F&O implementations.

5

Thank you for your response. The partner stated that our proposed process violates Microsoft’s compliance. I have reviewed the Licensing Guide, but I couldn’t find a clear section addressing the solution we are trying to implement. Could you point out exactly where this is stated?

6

Hi @Maria_Alice_Santana

You’re right, the Licensing Guide doesn’t explicitly cover every implementation pattern. These scenarios are usually interpreted based on Microsoft’s licensing and multiplexing principles rather than a single documented example.

If your partner believes this isn’t compliant, I’d ask them to point you to the specific Microsoft documentation or licensing guidance they’re relying on. Since they know your environment, they should also be able to raise a licensing clarification with Microsoft if there’s any doubt.

You shouldn’t have to struggle with this on your own. I’d be interested to hear what response they receive.

7

Thank you for the guidance so far, @Hardik_Gupta.

I want to emphasize that our primary goal is 100% full compliance with Microsoft licensing rules, not finding workarounds. We want to ensure our proposed architecture for retail stores strictly adheres to Microsoft guidelines before implementation.

Our Operational Context:

Headquarters / Business Center (HQ): Users are fully licensed with Finance and Supply Chain Management (SCM).

Store / Branch Users: Intended to be licensed as Team Members.

Proposed Architecture (Custom Draft/Staging Forms inside D365 F&O):

To keep store users compliant while avoiding direct interaction with core transactional tables, we are designing custom staging forms/tables built directly within the D365 F&O environment (e.g., a “Draft Notes / Requests” workspace shortcut using the 15 custom tables allowance under the Team Member license).

User Experience: The store user stays entirely inside the native D365 F&O interface without opening external apps, tabs, or third-party tools.

Here is how the 3 main workflows would function:

Procurement & Vendor Invoices:

Store user creates a Purchase Requisition (Team Member).

HQ Buyer creates the Purchase Order (SCM).

Store user performs physical receiving (Team Member).

Store user inputs vendor invoice details into a custom draft form/table directly within D365 F&O (staging area).

An automated batch/API creates the official pending invoice, and HQ Tax/Finance (Finance) reviews, approves, and posts it.

Sales & Invoicing:

Store user enters sales details into a custom draft form/table inside D365 F&O.

An automated background process creates the actual SalesLine / SalesTable records.

HQ Tax/Finance (Finance/SCM) or automated services finalize, invoice, and generate payment slips.

Payment Journals & Expenses:

Store user enters payment provisions or expense details into a custom draft form/table inside D365 F&O.

An automated process creates the LedgerJournalTrans lines.

HQ Finance (Finance) approves and posts the journal.

Backing Background Creation with Operations – Order Lines:

All background creation of core transactional entities (SalesLine, VendInvoiceInfoLine, LedgerJournalTrans,etc..) triggered from the custom staging tables will be executed via a service principal/API and backed by the Dynamics 365 Operations – Order Lines (tenant-based transaction) license.

Questions for the Community:

Does using custom staging tables (within the 15-table limit) for Store Users to input draft/request data directly inside the D365 F&O UI—while automated processes handle core table generation backed by Operations – Order Lines—fully satisfy Microsoft compliance for Team Member users?

Since users remain inside the D365 F&O application (without switching tabs or external portals) to fill out these custom draft forms, does this native UI interaction present any licensing compliance issues for Team Member tier?

Are there any specific pitfalls with this draft-staging model when using Operations – Order Lines for indirect transaction logging?

We are also requesting our implementation partner to submit an official query to the Microsoft Licensing Desk. Thank you for your valuable insights!

8

Hi @Maria_Alice_Santana

Excellent approach. Your architecture is solid: custom staging tables with Team Members inputting data, automated background processes handling core transactions backed by Operations – Order Lines. This model aligns with Microsoft licensing intent.

A couple of quick points for your Licensing Desk query:

  • Emphasize that Team Members interact only with custom staging tables (the 15-table allowance), never core transactional tables
  • Highlight that the service principal/API owns transaction creation, not the Team Member
  • Include your audit trail approach so they see clear accountability

Your implementation partner is on the right track going to Microsoft directly. They’ll give you the definitive answer.

Good luck with the submission; happy to support if you need technical validation after you get Microsoft’s confirmation.