Architecture CRM
Architecture CRM et Salesforce qui soutient
l'organisation également dans deux ans.
Planification complète de l'architecture — solution, données, sécurité, automatisation, intégration et environnements — pour que le système fonctionne aujourd'hui et puisse continuer à croître.
À qui s'adresse ce service
Quand il est judicieux d'intégrer un architecte Salesforce
- Organisations qui planifient leur première implémentation de Salesforce.
- Systèmes existants ayant perdu leur ordre et une architecture claire.
- Organisations qui planifient des intégrations profondes avec un ERP, la finance ou la BI.
- Équipes CRM qui cherchent à réduire la dette technique avant une nouvelle phase.
Problèmes résolus par ce service
Les signes qu'un système a perdu son architecture
Champs accumulés sans modèle
Après deux ou trois ans, chaque département a ajouté ses propres champs. Le résultat : des objets avec plus de 300 champs, des rapports peu fiables et des automatisations qui échouent. L'architecture définit les responsables, les règles de création et un cycle de vie pour chaque champ.
Automatisations qui se contredisent
Flow, Process Builder et triggers exécutant en parallèle sur le même événement. Nous consolidons dans une seule couche d'automatisation avec un ordre d'exécution prévisible.
Permissions devenues un trou de sécurité
Profils ouverts 'temporairement' il y a deux ans et jamais fermés. Nous construisons un modèle basé sur des ensembles de permissions et des rôles réels.
Intégrations sans responsable
Quand quelqu'un part, personne ne sait comment elles fonctionnent. L'architecture inclut la documentation, les journaux et une responsabilité claire pour chaque connexion.
Couches
Les couches d'architecture que nous concevons
Architecture de solution
Alignement des processus métier clés avec les produits Salesforce, y compris la priorisation de ce qui est inclus dans la première version par rapport aux phases ultérieures.
Architecture des données
Modèle d'objets et de relations, sources de vérité, règles de qualité des données et un plan de nettoyage et de consolidation des enregistrements existants.
Sécurité et partage
Profils, rôles, groupes publics, modèle de partage, champs protégés et politique d'accès aux informations sensibles.
Architecture d'automatisation
Choix délibéré entre Flow, Apex et l'automatisation asynchrone, évitant les automatisations parallèles déclenchées par le même événement.
Architecture d'intégration
Directions de flux, techniques (REST, événements, middleware), gestion des erreurs et journalisation pour les intégrations métier critiques.
Environnements et versions
Structure de sandboxes, une méthodologie de déploiement, sauvegardes, gestion des versions et opérations de maintenance continue.
Principes de travail
Principes qui guident chaque décision
- Configuration avant le code : développement sur mesure uniquement lorsqu'il n'y a pas de moyen plus simple.
- Toute modification architecturale est documentée et approuvée.
- Un modèle de permissions simple et clair, même au détriment d'une certaine flexibilité.
- Jamais deux automatisations ne s'exécutent en parallèle sur le même événement.
- Toute intégration inclut la journalisation, la gestion des erreurs et une zone de responsabilité claire.
- Tout nouveau déploiement passe par un sandbox avant la production.
Environnements
Structure d'environnements recommandée
Développeur
Pour le développement quotidien, sans données réelles.
Intégration / QA
Pour les tests système et l'intégration entre les composants.
UAT
Une copie similaire à la production pour les tests d'acceptation par les utilisateurs.
Staging / Pré-Prod
Un environnement de répétition pour la mise en production et les corrections urgentes.
Production
L'environnement en production, avec un processus de déploiement contrôlé uniquement.
Point de décision
Révisez votre architecture
Un bref appel aide à clarifier si vous avez besoin d'une nouvelle planification d'architecture ou d'une refactorisation spécifique de composants critiques.
Facteurs de décision
Quatre décisions qui déterminent la stabilité du système
Multi-org vs. org unique
Quand il est préférable de séparer vers un org distinct plutôt que d'utiliser intelligemment les types d'enregistrements et le partage. Une décision aux conséquences à long terme.
Gestion des données de référence (MDM)
Salesforce est-il la source de vérité des clients, ou la vérité réside-t-elle dans l'ERP ? La réponse détermine la direction du flux de chaque intégration.
Stratégie d'automatisation
Quand utiliser Flow, quand Apex, quand les Platform Events. Un mauvais choix crée un système difficile à maintenir.
Politique de champs personnalisés
Qui est autorisé à ajouter un champ et par quel processus. Sans cette politique, tout système se remplit de champs inutiles en un an.
Ce que vous obtenez
Livrables possibles du service
Document d'architecture
Solution + données + sécurité + intégrations, avec suffisamment de détails pour permettre le développement.
Carte des intégrations
Direction du flux, technique, type d'événement et scénarios d'échec pour chaque connexion critique.
Modèle de données
Objets, relations, champs clés et règles de qualité initiales.
Modèle de permissions
Profils, rôles et une politique de partage conforme à la structure de l'organisation.
Erreurs courantes
Modèles à éviter
- Permettre à chaque département d'avoir son propre modèle de données sans une vision transversale.
- Construire des automatisations en Flow et en code en parallèle sur le même événement.
- Déployer directement en production sans passer par un sandbox.
- Laisser des profils 'temporaires' avec 'Modifier toutes les données' sans jamais les réviser.
- Construire une intégration ponctuelle sans la documenter ; elle devient une boîte noire en quelques mois.
Guides et services connexes
Approfondissez vos connaissances dans le centre de connaissances
Foire aux questions
Architecture CRM — questions fréquentes
Qu'inclut une bonne architecture CRM ?
Quand un architecte Salesforce dédié est-il nécessaire ?
Est-il possible d'améliorer l'architecture d'un système existant ?
Combien de temps faut-il pour planifier l'architecture CRM ?
L'architecture CRM se limite-t-elle à Salesforce ?
Prochaine étape
Validez votre architecture avant de construire
Nous examinerons ensemble votre modèle de données, vos permissions et vos intégrations, et nous vous indiquerons les décisions qu'il convient de définir le plus tôt possible.
Prochaine étape