CRM materialisation
EPMS and D365 are separate Dataverse environments. Virtual tables where EPMS only needs to read D365 data and nothing depends on it structurally; copy/sync for the core tables — Account, Contact and anything EPMS must build relationships onto or expose through the portal.
Why Account and Contact cannot be virtual tables
- — A lookup from a custom table cannot target a virtual table in the way EPMS needs. seco_project.seco_account, seco_request.seco_account, seco_actionshare.seco_account and a dozen others all point at Account.
- — Power Pages table permissions require real rows. The Account and Contact scopes read contact.parentcustomerid on real records; portal identity cannot anchor on a virtual table.
- — Many-to-many relationships and alternate keys are not available on virtual tables.
- — Account carries 283 custom columns in D365 and EPMS needs a handful. A replicated subset is smaller, faster, and does not drag the CRM's customisation surface into the EPMS environment.
Replicated — copied into the EPMS environment (6)
Real rows in EPMS. Lookups, alternate keys, many-to-many relationships and Power Pages table permissions all work against them.
| Table | Sync key | Note |
|---|---|---|
| account | seco_crmreference | Replicated from D365 into the EPMS environment. Not a virtual table — EPMS builds lookups onto it, exposes it through Power Pages, and needs an alternate key. A subset of columns only; EPMS does not mirror the CRM's 283 custom columns on Account. |
| contact | seco_crmreference | Replicated from D365 into the EPMS environment. Not a virtual table — EPMS builds lookups onto it, exposes it through Power Pages, and needs an alternate key. A subset of columns only; EPMS does not mirror the CRM's 283 custom columns on Account. |
| seco_channel | seco_crmreference | Replicated rather than virtual: EPMS lookups point at it, and administrators need seco_sortorder and statecode on the EPMS side. |
| seco_country | seco_crmreference | Replicated rather than virtual: EPMS lookups point at it, and administrators need seco_sortorder and statecode on the EPMS side. |
| seco_customersegment | seco_crmreference | Replicated rather than virtual: EPMS lookups point at it, and administrators need seco_sortorder and statecode on the EPMS side. |
| seco_strategicaccount | seco_crmreference | Replicated rather than virtual: EPMS lookups point at it, and administrators need seco_sortorder and statecode on the EPMS side. |
Virtual table — read live from D365 (1)
Read-only. EPMS never writes them and nothing depends on them structurally, so no copy is needed.
| Table | Sync key | Note |
|---|---|---|
| seco_growthpillar | — | Read-only from D365; EPMS never writes it and nothing depends on it structurally. |
Not sourced from D365 (67 tables)
EPMS owns these outright. No dataflow, no virtual table, no sync key.
businessunitseco_actionseco_actionlogseco_actionshareseco_agreementseco_approvalchainseco_approvalstepseco_assignmentseco_bdcountrypoolseco_capacityentryseco_changerequestseco_clearanceseco_commercialapproverpolicyseco_configauditseco_configsettingseco_costlineseco_costrateseco_costsubcategoryseco_countryteamseco_countryteammembershipseco_crmfieldmapseco_declinereasonseco_delegationseco_deliverableseco_deliverabletypeseco_documentrequirementseco_documenttypeseco_eventseco_externalaccessseco_externalaccesspolicyseco_featureflagseco_feedbackseco_gatetemplateseco_gatetemplatestepseco_ihubseco_integrationlogseco_invoicemilestoneseco_machinetypeseco_materialseco_notificationtemplateseco_projectseco_projectaccessgrantseco_projectbudgetseco_projectgateseco_projectparticipantseco_projecttypeseco_proposalseco_reportingaudienceseco_requestseco_requestraisergroupseco_requiredfieldruleseco_resourceseco_resourceskillseco_restrictionhandlingseco_retentionpolicyseco_routingruleseco_scopeprofileseco_skillseco_sowseco_sowlineseco_timeentryseco_tutorialseco_userprofileseco_viewonlybucketsystemuserteamtransactioncurrency