Profielen en permission sets beheren in versiebeheer

Kort antwoord: zet permission sets in versiebeheer als de echte bron van waarheid, decomponeer ze zodat twee mensen ze kunnen bewerken zonder merge-conflict, houd profielen dun en behandel elke profieldeployment als een overlay in plaats van een volledige vervanging. Stop daarna bewust met het tracken van wat omgevingsspecifiek is, want het meeste profielverkeer in een repo is ruis die niemand leest.

Waarom zijn profielen zo lastig in Git te houden?

Twee gedocumenteerde gedragingen maken profielen anders dan elk ander bestand in je repo.

• Een retrieve is contextafhankelijk. Het opgehaalde .profile-bestand bevat alleen beveiligingsinstellingen voor de andere metadatatypen die in hetzelfde verzoek staan. Vraag een profiel alleen op en je krijgt bijna niets; vraag het samen met 40 objecten op en je krijgt een ander bestand (Metadata API-documentatie).
• Een deploy is een overlay. Rechten die niet in het bestand staan worden niet verwijderd in de doel-org, en een recht uitzetten vereist expliciet de waarde false in de XML. Een ontbrekende regel betekent "geen mening", niet "uit".

Combineer die twee en hetzelfde profiel levert een andere diff op, afhankelijk van wie het ophaalde en wat er verder in het pakket zat. Daarom zijn profieldiffs de meest bediscussieerde en minst vertrouwde bestanden in de meeste Salesforce-repositories.

Wat veranderde er in 2026, en verandert dat je strategie?

Salesforce had aangekondigd dat rechten in profielen vanaf Spring '26 zouden worden uitgefaseerd. Op 6 juni 2026 is die handhaving geannuleerd, met verwijzing naar klantfeedback en resterende functiegaten, terwijl Salesforce een permission-set-gedreven beveiligingsmodel bleef aanbevelen (Salesforce Help).

Praktisch gelezen: de deadline is weg, de richting niet. Profielen blijven ondersteund, dus niemand hoeft in paniek te migreren, maar als je kiest waar je je discipline in versiebeheer investeert, investeer die dan in permission sets. Die zijn additief, ze decomponeren en ze mergen.

Hoe decomponeer je permission sets zodat ze niet meer botsen?

Een opgehaalde permission set is een groot XML-bestand met elk object-, veld- en gebruikersrecht. Twee admins die twee ongerelateerde velden aanraken botsen in hetzelfde bestand. Salesforce levert hier een oplossing voor in de CLI: source behavior options die het bestand splitsen in een bestand per rechtengroep (Salesforce DX developer guide).

1. Commit eerst alles. Dit herschrijft bestanden op schijf, dus begin met een schone tree.
2. Draai het als dry run: sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. Draai het echt. Je sfdx-project.json wordt bijgewerkt zodat het gedrag voor iedereen blijft gelden, en de bestaande source wordt ter plekke omgezet.
4. Commit de conversie op een eigen branch, zonder functionele wijziging erin. Reviewers kunnen geen diff lezen die een formaatconversie mengt met echte aanpassingen.

Hetzelfde mechanisme dekt custom labels, workflows, sharing rules en external service registrations. Let op de leemte: profielen staan niet op de lijst met decomponeerbare typen. Objecten en objectvertalingen decomponeren standaard, de rest is opt-in beta, en profielen blijven een bestand.

Waar moet je mee stoppen met tracken?

De helft van de pijn is zelf veroorzaakt. Dit hoort buiten de repo, of achter een bewuste uitsluiting.

• Rechten van managed packages. Namespaced object- en veldrechten verschijnen en verdwijnen met packageversies per org. Ze tracken garandeert permanente spookdiffs.
• Login-IP-reeksen en inlogtijden. Dat is meestal omgevingsbeleid, geen releasecontent, en het verschilt terecht tussen sandbox en productie.
• Toewijzingen van permission sets. Dat zijn records, geen metadata. Wie welke set heeft is data en hoort bij een data-seedingstap, niet in Git.
• Rechten op standaardobjecten die je nooit wilt wijzigen. Beheert je proces ze niet, dan voegt ophalen alleen diffvolume toe.
• Profielen die je niet deployt. De meeste orgs hebben geerfde profielen die al jaren niemand aanraakt. Track de profielen die je pijplijn echt promoot.

Leg de uitsluitingen vast als regel in de repo, niet als stamkennis in de CLI-historie van een persoon. Een regel die in iemands shell-alias woont, breekt bij de eerste retrieve van een nieuwe collega.

Hoe verplaats je rechten veilig van profielen naar permission sets?

1. Kies een profiel en inventariseer wat het echt verleent in productie, niet in de sandbox waar het is afgedreven.
2. Maak permission sets per taak, niet per functietitel. Taakvormige sets worden hergebruikt; titelvormige sets worden voor elke nieuwe titel gedupliceerd.
3. Wijs de nieuwe sets toe naast het profiel en verander verder niets. Toegang is additief, dus niemand verliest in deze fase iets.
4. Haal de verplaatste rechten in een aparte release uit het profiel, met expliciete false-waarden zodat de deploy ze echt uitzet.
5. Verifieer met een gebruiker van dat profiel in een sandbox en bewaar de rechtensnapshot van voor de wijziging tot je dat gedaan hebt.

Doe stap drie en vier nooit in dezelfde release. Additieve en subtractieve rechtenwijzigingen hebben totaal verschillende rollbackverhalen, en ze mengen is hoe een maandagochtendlockout ontstaat. Meer release-engineeringplaybooks staan in onze SF Guides-bibliotheek.

FAQ

Zijn profielen of permission sets de bron van waarheid?

Permission sets. Ze zijn additief, ze decomponeren in mergebare bestanden en Salesforce beveelt een permission-set-gedreven model aan. Houd profielen voor basisinstellingen zoals licentie, standaard recordtypes en page layouts.

Worden rechten in profielen uitgefaseerd?

Nee. De uitfasering die voor Spring '26 gepland stond, is op 6 juni 2026 geannuleerd. Migratie gaat nu op je eigen tempo in plaats van op een deadline.

Waarom verandert mijn profieldiff terwijl ik niets deed?

Omdat een profiel-retrieve alleen instellingen teruggeeft voor de metadata in hetzelfde verzoek. Verander de pakketinhoud en het bestand verandert. Repareer het retrieve-manifest, niet het bestand.

Kunnen profielen net als permission sets gedecomponeerd worden?

Vandaag niet. De source behavior options van de CLI dekken permission sets, custom labels, workflows, sharing rules en external service registrations. Profielen blijven een bestand, wat opnieuw pleit voor dunne profielen.