Luís Fernandes Arquiconsult, SA (LCSS)

When creating a new "Account" in Dynamics 365 Sales, if Dual Write is enabled for this entity, the record is synced to Dynamics 365 F&O as a "Customer". As in Dynamics 365 Sales, the Account entity does not enforce validations on Account Address fields, users can freely type whatever City, State, District, Zipcode, Country they wish. As these fields are enforced by Data Lookups on D365 F&O, if the user does not insert a valid field in Sales (valid = existing in F&O), the record creation fails, due to a data sync failure.

If a deployment of F&O and CE is expected in enterprise environments with harmonized and consistent data sync among such relevant entities, data lookups and validations should be enforced and enabled in CE when creating an Entity Address, so users are not disrupted while creating master data, and a recurrent customization is not required for every single deployment.

Thank you.

On "User Options", a user can select what should be his home screen experience when loging in. It would be quite useful that we could assign a specific workspace from the list of standard workspaces the user has access to. Eventually even to custom workspaces. Most users interact with the solution in a given workspace every single day, so accessing a list of 2 or 3 workspaces, and click always on the same one to see relevant data is an efficient approach on the interaction with the solution.

While setting up document handling and the overall attachment framework, customers perfer external file repositories like SharePoint, specially in a moment where capacity-based licensing is being enforced. When specifying a document type, a SharePoint URL is defined and all attachments of this type are uploaded to the directly within that URL is SharePoint. When a user uploads and then opens the file, he's redirected to the file itself, but the URL can be reverse-engineered and the root folder can be accessed, allowing full access to all files in the folder (assuming the user has access to it). This model, when applied to SharePoint-based document types means that:

1. Any user can upload any file type in any entity (customers, PO's, Fixed Assets, Employee cards, etc)
2. The file attachment only works if the user has access to the SharePoint directory associated to the configured document-type URL
3. Any user that can upload a given document-type, can also navigate to SharePoint and see all documents in the system associated to that document type.
4. To restrict a user to see a sub-set of documents, in SharePoint, we need to specify different document types, assign each type to a specific SharePoint URL (folder) and apply security rules on that folder (via SharePoint).
5. The point above frequently turns into a 50+ list of document types, which all show up listed in an attachment-enabled form, generating a very inneficient experience to users, prone to errors and confusion

Proposal:

1. When configuring what tables are "active" for document attachments, allow the specification of what type of documents are allowed. This way, a given entity (say, "Customers"), would only allow users to upload document types configured as relevant with that entity, while all others could not been seen neither selected on the attachment type list (after they click on the little paperclip icon).