What a Customer or Partner Portal Is
The Customer portal is a Power Apps portals template for B2B sales order processing that lets companies create an externally facing website. On the partner side, the Supplier Engagement solution provides tools for managing external supplier users through the Supplier Engagement app and the supplier portal.
Those internal systems may include ERP, MES, WMS, QMS, CRM, EDI feeds, data platforms, and file repositories, depending on the environment. ISA-95 is an international standard for integrating logistics and manufacturing control systems. That framework describes the interface layers your portal requirements must cross.
How Operational Records Reach the Portal
First, a synchronization layer moves records from the operational system of record to a data layer the portal can query. Dual-write is an out-of-box infrastructure product that provides near-real-time interaction between customer engagement apps and finance and operations apps. That sync is not automatic for every table.
Before data from Supply Chain Management can be surfaced in the Customer portal, dual-write must be enabled for all the appropriate tables. Your requirements plan must list every table that needs to be enabled and confirm ownership for that enablement step.
Second, the portal layer reads from that synchronized data layer through virtual records rather than direct database access. Access is exposed through Dataverse virtual entities, which surface Supply Chain Management records to the portal.
Supplier portal user management is based on an integration between Microsoft Power Pages (Dataverse) and Supply Chain Management. Together, these systems control authentication, role assignments, and access to both portal content and supply chain data.
For data that originates in MES or WMS rather than ERP, the integration boundary shifts.
ISA-95 Part 5 defines transactions in terms of information exchanges between applications performing business and manufacturing activities associated with levels 3 and 4 of the ISA-95 model. The ISA-95 standard primarily deals with the interface between levels 3 and 4.
That crossing is a separate integration requirement with its own ownership and validation steps.
Supported Use Cases
Three use cases belong in a governed implementation plan.
Permissioned self-service for customers. Customers can view order status and submit new orders without contacting your team. Orders submitted through the Customer portal are automatically synced to the corresponding Dynamics 365 Supply Chain Management environment. The requirement here is defining which order fields are visible, which are editable, and which are automatically populated from the contact record.
Controlled partner access. Partners see only the data that belongs to them. Extensible data security (XDS) policies restrict data visibility, ensuring that users see only data that belongs to their vendor. Where the goal is to limit access to specific processes, scoped transactional roles are available for that purpose. Role combinations are supported.
You can also combine transactional web roles. For example, you can assign a user both the Purchase Order User role and the Request for Quotation User role if they should only participate in these two processes, without accessing invoices or consignment inventory. The requirement is a role matrix that maps each external user type to the processes they need.
Limitations and Distinctions That Belong in the Plan
Confusing them creates scope problems during delivery.
The template is a starting point, not a finished product. By itself, the template isn't expected to be completely functional. It just serves as an enabler for customers who want to create an externally facing website so that enterprise customers can engage with data from Supply Chain Management. A requirement document must specify what the template provides out of the box and what needs to be built or configured on top of it.
Data table prerequisites are fixed requirements, not options. Don't remove the following columns from the sales order table in Microsoft Dataverse, because they are required to create a sales order in dual-write. These columns include company, name, currency, price list, ship-to country, potential customer, language, and delivery address. Each is a hard dependency. Your plan should list them explicitly and assign a validation owner.
Identity mapping has a non-negotiable prerequisite. Each contact must have a unique email address to ensure proper identity mapping.
Governance ownership must be assigned, not assumed. Administrators configure portal roles and vendor assignments in the Supplier Engagement app, while Supply Chain Management enforces access to supply chain transactional data. Your plan needs a named owner for each layer.
Integration standards define scope, not delivery. The identification of the organization and owner of each system and the lifecycle management of the equivalent object namespaces is outside the scope of this standard. ISA-95 describes the interface model. It does not assign ownership of systems or namespaces. Those decisions belong in your requirements document.
Which Requirements Belong in a Governed Implementation Plan
The reader decision is concrete: separate fixed prerequisites from configurable choices before the project starts. Use these checks to build that separation.
-
Map every data type to its source system. List each record the portal must display. Name whether it lives in ERP, MES, WMS, QMS, CRM, or another system.
-
Confirm dual-write table enablement. Identify every table that must be enabled before portal data can appear. Assign a named owner for that step. This is a fixed prerequisite, not a configuration option. Each crossing needs its own integration requirement, owner, and validation step.
-
Define the data boundary for each external user type. Specify what each customer or partner role can see and do. Confirm that XDS policies or equivalent security controls enforce that boundary before go-live.
-
Build a role matrix. Map each external user type to the specific processes they need. Where the goal is to limit access to specific processes, scoped transactional roles are available for that purpose. Confirm that role combinations are intentional and documented.
-
Verify contact record completeness. Every contact must have a unique email address before portal provisioning begins. Required Dataverse columns for order creation must be present and assigned a validation owner.
-
Name the governance owners. Assign one administrator responsible for portal role assignments and a separate administrator responsible for Supply Chain Management access enforcement. Both layers need a named owner.
-
Separate fixed prerequisites from configurable choices. Fixed prerequisites include dual-write table enablement, required Dataverse columns, and unique email addresses. The template supports customization of appearance and functionality on top of those prerequisites. Mixing the two categories creates scope disputes during delivery.