If you are an university using Salesforce crm or planning to use SFDC, one of the daunting questions always is how do we manage student data between SFDC and Banner , how do we deal with conflicts where the record is created in SFDC and Banner at the same time and how do we deal with children objects like education history, documents or attachments etc. This blog would help you to create a strategy to handle integration issues with Banner and other systems easily.

Defining System of records for banner and SFDC

Most of the universities have the view that salesforce should be the system of engagement and banner should be the system of records. But the problem is defining what the system of engagement means and system of records mean.

To make it easier, base this definition based on student lifecycle. So if a student stage is recruit or suspect or till the student registers for a undergrad or grad program and his application is approved, all updates can be made in salesforce only. Data would be pushed to banner but in case of a data conflict where updates are done on both systems, banner data can be overwritten by sfdc.

If the student is a registered student, that is once his application is approved, then Banner would be the source system and all updates would be done on banner only. Any changes in case of a data conflict between 2 systems would be resolved with Banner as the source system and overwritten on the salesforce side on potential conflicts.

Decisions on child records

If your university uses child objects like education history, touchpoints or activities, employment history etc, then a clear distinction should be made on where the creation and updates would be made from a system perspective. For this decision, the following criteria would help.

1. If all the child objects are updated from different departments in your university, then Banner can be the source system and data pushed to SFDC for synchronization purposes.

2. If the child objects would be managed only by the recruitment and marketing team and they have access to salesforce, SFDC could be the source system and updates would be pushed to banner for synchronization purposes.

3. For tracking activities done by the staff  on student or application data, both systems can be considered as the source system and updates done on both end. Using activity date, activity type and student or application record, duplicates should be checked and synchronization can happen in both systems.

Flagging data conflict records for review.

In a scenario on data conflicts where updates are done on both system, your synchronization process should be capable of identifying the conflicts based on date updated and all the records should be flagged for review. Creating a report on these conflicting records in salesforce and assigning it to an user who can manually decide on the conflicts would help to avoid future duplicates and data discrepancies.

Business process change

Once the system of records and engagement has been defined based on lifecycle of the student, your Grad and Undergrad department users should be notified on the process change. Training should be provided to the users to let them know on which system they can make changes based on the student lifecycle.

Key takeaways.

1. Define system of records based on student life cycle.

2. Use ease of use and system access for all users at all times as a basis to define source system for child objects.

3. Keep mechanisms to handle conflicts

4. Have a training plan to train the users on business process change.

So using the above  strategies , data conflicts between sfdc and banner can be avoided and integration can be made simpler. Feel free to post your comments on how you are resolving integration issues and you can always email me at buyan47@gmail.com for further questions.