[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 mois par  R3dKap.

[MarKAR]

Bonjour Emmanuel @R3dKap

Merci pour ta réponse détaillée et tes idées précieuses

J’ai creusé le sujet sur une longue période afin de trouver la meilleure façon de modéliser.

D’abord il y a le volet migration des données depuis sharepoint. J’ai commencé un Dataflow mais le modèle de données change radicalement et dans la pratique pas vraiment évident à implémenter dû à la différence des entités. d’ailleurs un des blocages que j’ai est la récupération des utilisateurs, Dataflow ne permet pas comme PowerQuery Desktop de split les données liste (multi-user SPField)

à première vue le modèle n’est pas très compliqué, mais essayer de le migrer dans Dataverse implique l’utilisation (pas forcément) des entités Dynamics CRM (qui logiquement devrait être plus fourni en possibilités). Mais je me retrouve à devoir créer autant de groupes (teams + groupe AD : 250 usines !) afin de pouvoir granuler les accès…

Tout ça me démotive à l’idée de migrer dans Dataverse ( qui était à la base une envoie de monter en compétence sur Dataverse )

Encore merci <3

• Cette réponse a été modifiée Il y a 3 mois par  MarKAR.

[R3dKap]

Je vois… Sinon pour migrer tes données de SP vers Dataverse tu peux aussi juste faire un p’tit bout de code sur un bouton dans une app Power Apps :

ForAll(
    TaListeSP As loopItemSP;
    Patch(
        TaTableDV;
        {
            ColDV1: ColSP1;
            ColDV2: ColSP2;
            ColDV3: ColSP3;
            etc...
        }
    )
)

Et tu faire des traitements particuliers sur les champs, des calculs, etc. Bref tu peux faire un peu tout ce que tu veux…

[DavidZed]

Vu l’envergure du projet, l’utilisation des BU / Teams me parait nécessaire.

Tu dis que tu as autant de groupes AD à créer que d’usines… Ces groupes n’existent pas déjà ? Généralement c’est quelque chose que l’ont fait en premier dans l’administration M365