Microsoft Dynamics 365 | Integration, Dataverse...

CE to D365 FO

(0) Share

Report

Posted on by VM-02050213-0

206

Hi,

I have a requirement where a field needs to be available in both D365 FO and CE.

The requirement is:

The field should be editable in CE during record creation and update.
The field should not be editable from the FO side.
The table is used across multiple forms in FO.

One approach would be to make the field non-editable at the form control level. However, since the table is used on multiple forms, this would require changes to all the relevant forms.

Is there any other framework-level or table-level approach that would allow the field to remain editable in CE while preventing users from editing it in FO, without having to modify every FO form?

Thanks,
VK

Categories:

Dynamics 365 general

All responses (11)

Answers (0)

Sort by

Martin Dráb 241,313 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

To prevent users from modifying a field (by forms and data entities) in F&O, you can set its properties Allow Edit and both Allow Edit On Create to No. Note that such a field can still be modified from code.
André Arnaud de Cal... 307,684 Super User 2026 Season 2 on at

Like (1)

Report
Copy link

Link copied!

Hi VK,

Can you tell what exact method you used for having a table using in both CE and F&O? Is it based on tables at both sides and syncing using Dual Write or are you using a table in F&O, exposed this as a public data entity and enabled the entity as virtual table in Dataverse?
Suggested answer

11manish 1,545 Super User 2026 Season 2 on at

Like (1)

Report
Copy link

Link copied!

Use FO security/field-level permissions as the first choice. Keep the field writable for the integration path, remove Update permission for normal FO users, and avoid changing every form. This provides the cleanest and most maintainable design for a field that is CE-editable but FO-user read-only.
VM-02050213-0 206 on at

Like (0)

Report
Copy link

Link copied!

hi @André Arnaud de Cal... This is for customer table. we added a field and yes they are using the dual write to sync and create the customer
@Martin Dráb I did the allow edit no at the table level but when CE was passing they noted that there was std error of not allowing to create/update the field as its non editable
@11manish can you please add more details.
do you mean xds or something , how do we restrict a single field on a table level via security,
or do you mean the std form wherein we select the table and then we give read etc , but that too did not work for me as the user was having admin rights to create customer.
Martin Dráb 241,313 Most Valuable Professional on at

Like (1)

Report
Copy link

Link copied!

@VM-02050213-0 As I mentioned, this also prevents updates by data entities. If you covered forms only, users could still change the data by data import, from Excel, from Power Automate and so on, therefore such a design wouldn't meet your business requirements.

But that updates are prevented by default doesn't mean that you couldn't implement the entity that you use for CE to make an update anyway.

Regarding the suggestion by 11manish, it's not about XDS. XDS is used for filtering data, while here we're talking about an access to field. Check out Field Level Security in Dynamics 365 for Finance & Operations, for instance.

Of course that security restrictions won't work if you use the system administrator role, but it's an extremely dangerous approach. Why do you want to ignore security and you want to give the account permissions not only to create customers, but also to do anything else with the whole system?
Suggested answer

Anitha Eswaran 436 on at

Like (1)

Report
Copy link

Link copied!

We had a similar requirement in D365FO where certain fields were considered master data maintained in another system and therefore should not be editable within FO. To address this, we implemented coc at the form level to make those fields read-only for users.
for your scenario, you should evaluate whether a form-level or table-level approach is more appropriate based on the business requirements. Consider factors such as whether the restriction should apply globally across all forms, whether it could impact other legal entities that do not require the same behaviour, and whether updates from integrations or other processes need to be allowed
Martin Dráb 241,313 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

@Anitha Eswaran What do you think about my remark that covering forms only isn't sufficient, because users can still change the value through Excel, a data import or so?
VM-02050213-0 206 on at

Like (0)

Report
Copy link

Link copied!

hi @Martin Dráb
yes agreed users can still change the data via excel addins etc and hence intitially i gave them only allow edit as no at the table level , but CE guys told thye were not able to edit the fields and encountering the standard cannot update error .
But if you say that this should work then I would recheck with them .
thanks for the reply.
@Anitha Eswaran thanks
Martin Dráb 241,313 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

@VM-02050213-0 You have to decide whether you can accept user changes or not. If not, then your current design cannot be used, because it doesn't meet your requirements. You solved one problem, but created a new one, and therefore it's not really a solution.

Now, please answer the question why you want to use a system administration account, which prevents you from solving your problem by security configuration and creates a large surface for mistakes and attacks.
Anitha Eswaran 436 on at

Like (0)

Report
Copy link

Link copied!

I agree @Martin Dráb - users still have several ways to update data. As users usually don`t have admin access , we can restrict access to entities so updates cannot be done using dixf or excel add in ..
Having said that, FO data can be accessed in various ways from external apps , so having priciple of least privilege for their role should be considered here.