How to do AB Testing on new features with your salesforce crm..

As a salesforce administrator or Manager, there is always needs from the business to test some features to a small audience and then roll out to a larger audience. With salesforce flexible platform, the challenge is to create a solution which would have minimal impact on the data if we decide to roll back, get it done quickly and leverage out of the box  features in Salesforce . This article would help you to come up with a quick strategy to implement AB testing which is a feature which google mastered on their products.

1. Decide the minimal features which you want to build.

Identify a minimal list of features which you want to build from the users.For all the features  identify screens, data and business rules which are part of the feature and create a matrix of the components involved.  If their are visual force pages and apex  involved on the feature, ensure that the development team should  code the apex classes which enforce the security profiles.

2. Identify data impacted by the feature.

Identify all the standard and custom objects used by the feature. If there is data import involved from external applications, identify external ids and synchronization keys which can be used to reference data. If the features involve integration with  external applications real time or batch mode, ensure that the application team uses salesforce id for cross reference. It is also important to understand whether the data modified by the new feature has to be exposed to higher level role users . Also record the profiles which this feature should never be exposed.

3. Design a security framework to expose it to the needed audience.

Make a list of profiles which you want the feature to be exposed. Ensure that for those profiles, all the objects have the right read and update permissions and field security is turned on. For profiles, which you do not want the features to be shown, ensure that the objects, fields, tabs are turned off. Focus on roles and public groups for data access and ensure that all your users with higher level roles would have the needed permission to view and update the data.

4. Rollback strategy on major disaster.

This would be a backout plan which you need to be aware of once you find the feature is really messing up  a lot of data and is really causing trouble. So for the roll back plan, all you would need to do is

a. Identify the data created and updated by the feature.

This can be easily queried by the users for which the feature was enabled. The last modified date and user fields can become handy to identify the data impacted.

b. Restoring permissions

If you change changesets or ant builds, restoring the configuration on permissions to the original state would remove the new features and revert it back. Subversion or dream factory tools can become real handy to restore back to the original state.

c. Handle customization’s

There might be one off customization like visual force or apex which need to recorded for rollback to revert to old state. By turning off permissions for the profiles can handle the new apex classes and visual force pages. For the code which was modified, code repository tools like github and subversion would really become handy to restore quickly. Any manual configuration changes should be recorded in a document so that it can easily be reverted back.

5 . Validating and making decisions to move forward on new feature.

Once the AB testing features are made live, there should also be a plan to validate how effective the new features work and when to roll out to all users. To validate the effectiveness of the new features, here are some things which can help.

a. adoption  – By auditing records modified or created by the new feature by users and groups in the form of reports, an adoption metric can be drawn out to validate the new feature.

b. support requests – Any new feature roll out should be followed by a plan for support. This would involve user requests for training, bug fixes. A quick chatter group with posts can also become handy on this. So the number of support requests could also be a metric to gauge the effectiveness of the new feature.

c. New user request – It is also important to identify new users who are requesting this feature which would help to validate the popularity of the new feature and judge future new users.

6. Roll out to all new users

Finally once the new feature is verified, there should be a release document which outlines on steps to be done to roll out to all users on the new feature. To do this, support groups can be formed among users who can help each other and improve adoption and change management process should identify all the components necessary to mitigate the change.

So using the above approaches, any organization can AB test their features in salesforce and provide steps to effectively monitor and roll out their new features to a large audience. I would appreciate if you could click like or reply to for further questions.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get free tips on Salesforce
Get free tips on Salesforce
We respect your privacy.