There are a ton of custom fields that I've had to manually modify permissions after the migration checking both "visible" on the FLS as well as Field Accessiblity. It's very painful to have to do this on each field individually. This seems like too much work. I almost feel that I've either done something wrong or missed an important step.
Therefore, is there a checklist of sorts on the proper steps to take to ensure this doesn't happen again? Did I miss something? I'm a new administrator and have nearly lost all of my hair trying to get the new org set-up. I have yet to import any test data--that's next. Unfortunately, I have failed miserably.
Because these sandboxes are of a different type, I cannot simply clone one sandbox after another. Why does Salesforce care when just migrating metadata? I get the data restrictions on the different type, but I haven't even gotten to a point to import any data yet.
Is there an order of operations to migrate metadata?
- OWD
- Roles
- Profiles
- Users
- Custom Objects & Fields
- Permission Sets
Is there such thing as the chicken and egg (which to migrate first) issue? I know some of these may be dependent on the other. Any ideas or suggestions?
I have read a few articles, but they don't address my concerns:
https://help.salesforce.com/articleView?id=changesets_implementation_notes.htm&type=5
https://help.salesforce.com/articleView?id=changesets_best_practices.htm&type=5
Help me Salesforce community, you're my only hope.
Thanks in advance.
3 risposte
Destructive changes usually mean deleting existing apex classes or custom fields, etc. Are you trying to deploy new profile which does not exist in the destination org with the fields? or the profile already exists in the destination org? If this is a new profile, it will take the FLS settings in the destination org.
