Associate SalesforceProfiles to Configuration Profile

[shivaranjini_g]

• Does it help if SalesforceProfile association to Configuration Profiles is handled by Migration Tool.

Today Migration Tool does not handle association of Salesforce Profile to Configuration Profiles. This is manual activity post migration.

• If we just check the Profile name (no other criteria considered) and associate to Configuration Profile, do you see a risk.
• The SalesforceProfiles associated with ConfigurationProfile in the source org if not listed in the target org then, does it make sense to associate only those that are available in target org or not associate any, if it is a partial list.
• Does an option for admin to make that decision during migration would help ?

From your experience:

1. How much overhead is this activity, manually map SalesforceProfile to respective configuration profile.

2. Do the Source org and Target org always have same set of SalesforceProfile and matching license type.

3. Typically maximum of how many group profiles would any customer maintain.

4. Have you ever felt this should have been taken care by tool, if yes the reason being...

5. Was there a scenario where target org had different SalesforceProfile association than Source org and it was expected to be that way.

Please share with Shivaranjini Gangadharappa​ your response to understand if this use case makes sense.

Any other feedback using Migration Tool is also welcome.

Thanks in advance.

[lisa_mercer]

Michael Majerus​  Jahnavi Gosula​

Would you mind answering these questions and providing your feedback?

[mmajerus6]

Hello Lisa Mercer, Shivaranjini Gangadharappa. I'm a big fan of making the Migration Tool more robust. One issue with the migration tool is that the SFW Layout Configurations do not migrate and this takes about 20 minutes per Org to correct and validate in each of our DEV boxes.

To date, we have not had any issue with Configuration profiles. We only have 2 SMax Configuration profiles and really only use 1 regularly. This Config profile has the correct Salesforce profiles associated to it in Production. When we migrate new SFW's, they arrive in Prod correct so I don't think we are affected by this limitation as much as others with multiple Config Profiles.

[acooper]

Totally agree with this: "One issue with the migration tool is that the SFW Layout Configurations do not migrate and this takes about 20 minutes per Org to correct and validate in each of our DEV boxes."

This takes us a huge amount of time in each sandbox, especially as you cant insert a new wizard at the top, without having to edit every wizard underneath it one by one...!

[shivaranjini_g]

Will an option that allow to insert wizard at any slot, or an option to select and move up/down help?

[shivaranjini_g]

Hi Michael, Wanted to discuss more regarding SFW Layout Configuration migration.

We can think of migrating SFM Wizards and layout configuration to match source org provided All SFM wizards are migrated, if target org has any additional wizards in its layout configuration it will be over written.

What if the user selects a specific SFM wizard for migration, in that case there are chances that, the slot as in source org would be taken up another SFM Wizard in on the target org. In this scenario we can either

1. Replace the slot with new wizard migrated , wizard that was already listed will have to be manually added if required on layout configuration post migration.

2. or move the new wizard to the end of the sequence.

3. Do not allow updating layout configuration if selective Wizards are migrated.

There is no way migrator tool will get to know list of that are added to the layout configuration.

Is there a scenario where target org might maintain some addition wizards in layout configuration. What if we are migration from different org. Have you seen such scenarios.

Please share your thoughts.

[mmajerus6]

Hello Shivaranjini Gangadharappa​. For us, we develop in a Dev box, then migrate to a QA box, then move to Prod. Our environments have to remain in sync as we move.

With that path in mind, we will always update the new SFW Layout configuration in each environment to support new SFWs. Today, we do that manually, but we are hoping the migration tool will move the layout configuration exactly as is in in the Dev source org to the target orgs. So, we don't want to insert a single SFW change to the layout configuration, we really want to overwrite the entire SFW layout configuration for that specific object.

We understand that if there are additional changes to the specific objects' SFWs in the Dev box, that those changes would also move with the object's layout configuration overwrite, but we manage our development pretty tightly so that is not a big risk for us. I propose that the migration tool would pop up a warning message about the overwrite like it does when overwriting SFMs.

When we are manually configuring an object's layout configuration in our Dev box, it would be great to have "an option to select and move up/down" the SFWs in the layout configuration UI. This would be especially helpful for customers whose Work Order Service Report language-based SFW layout configuration contains 20+ SFWs representing each of the different languages. This is a common SMax configuration solution.

sfw​ SFW_layout_configuration​ ui​ bio-rad​  Lisa Mercer​ 

[lisa_mercer]

Pavan Kumar​ Susan Michel​

Would you mind answering these questions and providing your feedback?

[smusku]

We have mire than 6config profile. Here are my answers in respective number sequence:

1. Every time we create profile and migrate Prod or a new Dev sandbox is created, its painful process to manually map sfdc profile to config profile.

2. We want to migrate source org config to target org.

3. 6 profiles we have in our org. We are 3more this release for lightning transformation and partner planner community.

4. Yes, tool should take care to minimize manual efforts and avoid human errors in manual process.

5. No.

I echo Michael Majerus comments above. Enable us to more productive with less manual steps.

[shivaranjini_g]

Sandeep Reddy Musku Michael Majerus

Thanks for the feedback on profile association

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. 

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.

Any thoughts on this?

[mmajerus6]

Answers In-line:

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​

[shivaranjini_g]

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

[pavan_kumar]

Hi Shivaranjini Gangadharappa​,

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:

1. Better Error Handling: We have seen situations wherein the Logs say that the migration was successful. However there were certain components that never got migrated.
2. Also, we recently had some changes getting wiped off from the Target Org after the migration. We don't know what would have caused this but this could be because of a missing component in the Target Org (or some additional components in the Target Org ). Therefore we need a more reliable pre-deployment validation to be done with warning messages if the Orgs are not in Sync.

[shivaranjini_g]

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.

[paul_hodgson]

Ramesh Kotamareddy​ Andrew Lieu​ Deborah Laughran​ would you have any insights into this topic that you would be willing to share? Thanks! Paul

[dlaughran]

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.

[paul_hodgson]

Thanks Deborah Laughran​!

[mbowyercrombie]

Hi Russell Jacobs​

I thought you might like to provide some input on this thread given the current projects at Domino...  It will also ensure we keep Lisa Mercer​ happy!

Matt

[lisa_mercer]

You are correct, Matt Bowyer-Crombie​!  And thank you, Russell Jacobs​!!

[russjaco]

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.

Thanks

Russ

[lisa_mercer]

Thanks, Russell Jacobs​!  I am happy!

[shivaranjini_g]

Thanks for the feedbackRussell Jacobs, the information helps. Just to be clear we will not be making any changes in the migration tool to migrate the permissions sets or any configuration managed at Salesforce level.

[shivaranjini_g]

Migration Tool release (19.1) will support Salesforce profile association when configuration profile is selected for migration.

On 'Validate'

• We will list associated Salesforce profile for the selected group profile with option to select all or select specific Salesforce profile for association.
• We will list Salesforce profile(s) that are not found in the target org (but associated in source org).
  • User will have to create those Salesforce profile(s) manually and perform assignment in target org.
• We will list extra Salesforce profile(s) associated with group profile in the target org.
  • User will have to manually un-assign them post migration.
• If  Salesforce profile(s) selected for association is already assigned to another group profile in target org then we will list those profiles and their group profile info.
  • It will be revoked from those profiles if selected for migration.

'Migrate'

• User will have to select 'Salesforce profile(s)' under group profiles to consider profile association for migration. If none selected then only group profile will get migrated(existing behavior).
• For the selected configuration profile, migration logs will capture details

1. Additional Salesforce profile(s) found in the target group profile,
2. List of Salesforce profile(s) that get assigned to the group
3. Details of group profile from which selected Salesforce profile will get unassigned &
4. List of Salesforce profile(s) that are missing in the target org

Note: Migration tool will not create Salesforce Profile in target org, only supports association of the Salesforce profile(s) to the group profile if already available in target org.