[R3dKap]

Salut @MarKAR,

Alors j’ai pas encore pratiqué l’utilisation des business units et des équipes D365 dans Dataverse mais voici quand même mon point de vue.

Si tu veux utiliser des business units et des équipes (on parle bien d’objets D365 exploités via le Dataverse) cela implique que l’entreprise s’est organisée (ou va s’organiser) pour définir toute sa structure via ces objets ; mais surtout il faudra qu’ils soient maintenus à jour -> il faut donc établir une gouvernance claire pour la mise à jour de ces données

Perso, j’aime les solutions simples et efficaces . Sur une grosse application Power Apps je m’étais “contenté” d’utiliser des équipes Dataverse et des rôles de sécurité : des équipes (dans lesquelles je mettais les bonnes personnes) et des rôles customs associés à chaque équipe.

Mais ce n’est que mon humble avis

NOTE : les équipes Dataverse (+ les rôles) servent à identifier le rôle (dans la vie réelle) et donc les droits d’un utilisateur dans l’application (du moins c’est comme ça que je les avais utilisés). Mais selon moi cela ne t’empêche pas de devoir indiquer dans tes tables les chefs et les responsables (voir ci-dessous).

Pour ce qui est donc du modèle de données j’identifie (de ce que j’ai compris) :

• Une table REGIONS
  • Chef de région
• Une table USINES
  • Région (lien vers REGIONS)
  • Chef d’usine
  • Responsable d’usine
• Une table TICKETS
  • Usine (lien vers USINES)
  • Validation région
• Une table TICKETS – VALIDATIONS USINES
  • Ticket (lien vers TICKETS)
  • Usine (lien vers USINES)
  • Validé (oui/non)

Je préfère une table TICKETS – VALIDATIONS USINES plutôt qu’une relation N-N “Validations usines” entre TICKETS et USINES parce-que j’ai plus facilement la main sur son contenu. Les relations N-N créent des tables masquées qui sont un peu relou (je trouve) à manipuler.

Mais tout ça reste à creuser selon le besoin réel…

• Cette réponse a été modifiée Il y a 3 jours, 14 heures par  R3dKap.