Proposed approach to associate Salesforce profile to the Configuration profile is:
1. Salesforce profile already exists in target org.
2. We will search for Salesforce profile based on name only.
3. If a particular salesforce profile does not exist in target org, it will not stop configuration profile migration, only that specific salesforce profile will not be associated in target org.
I would stop the config profile migration and show an error message about the missing profile. Since the profile is missing in the target org, it should be added before migration or removed from the source configuration profile before migration. This will keep the source and target orgs in sync. If the configuration profile had been migrated without the intervention, then the target would be missing the Salesforce profile and would cause issues in the future for users in that profile.
4. Migration will replace/maintain 'salesforce profile' association as per source org for a selected configuration profile. Any additional profiles there were associated with the selected configuration profile in the target org will be removed.
I would warn the user about the Salesforce profile mismatch and list the specific Salesforce profiles that will be removed in the target org if migration proceeds. If the user clicks 'Ok' then I would proceed with the migration with the understanding that the profiles will be intentionally removed in the target org.
migration tool bio-rad Lisa Mercer
Re 3 #, We had considered about showing these details in logs
Re 4#, Remove here means un-assign. Post migration target org assignment will be same as source org. If Source and target org are identical then this issue shouldn't occur.
We will revisit the error handling in these scenario. Thanks
I don't think being able to migrate the associations between the Salesforce Profiles and the Service Max Configuration Profiles will help us a lot. The reason being that we do not create new profiles or associations (with the SMAX Configurations Profile) so often and handling such changes once a while manually doesn't hurt . But I understand it might not be the case with all other customers so having this feature would definitely benefit a lot of people out there. Therefore my vote is to have this feature be available in the migration tool (although it would be a "nice to have" for us).
Regarding your approach #3, I would say that you show some sort of a warning message if a Salesforce profile is missing in the Target Org. This way the customer can decide if they choose to ignore the warning and proceed with the deployment OR fix the issue before the migration can happen. (Just like the migration tool shows a message today for the items that will/will not be migrated).
Regarding your approach #4, I don't think it is right to override the Target Org without showing some sort of warning message indicating that the Source and the Target Orgs are not in sync and the changes will be overwritten. You could probably show a list of additional profiles that are only associated in the Target Org's Configuration Profile (and missing from the Source Org).
Few other improvements we would like the migration tool to have are:
Hi Pavan Kumar
Thanks for feedback, we are looking in to how to show more detailed info post validation.
Regarding the improvements suggested,
Re Pt1# it would help if you could share more details. Which of the items were selected for migration that didn't get migrated but logs said successful.
Re Pt 2# Pre requisite is to have the custom component that has dependency to be created in target org before initiating migration.
We have a backlog item to capture more details in the validation screen and logs so that admin has more clarity.
As we do not often make changes to our ServiceMax Configuration Profiles, this is not a big issue for us. I agree that having them included in the migration tool is a good idea although it would not be a high priority for us.
Regarding your proposed approach for #3, I would agree with Pavan that you should show a warning message if a Salesforce profile is missing in the Target Org and allow the admin to decide if they choose to ignore the warning and proceed with the deployment OR fix the issue before the migration is executed.
I agree with your proposed approach for #4. I must know there are changes in the Configuration Profile or I wouldn’t be migrating it.
Well we must keep Lisa happy!
I can understand the need, but its not something we have an issue with; we only have 5 profiles for Servicemax users, this was something decided upon at the beginning of the project back in 2009 and i believe has saved us a lot of grief over the years. We have a strict policy of not creating new profiles, and rarely change our profile set ups, any security changes required would normally done through permission sets.
As we have so few profiles, they are in all of our sandboxes as well as on Prod, and if we ever have to migrate any changes to a profile, we just role it up in to the Salesforce change set that we would normally deploy before we do a Smx migration.
Now if the Servicemax migration tool could generate a change set for us, that would be real game changer.