You'll need to create a plan for how to keep your data models synchronized. Data must be pulled from 360Alumni's API rather than pushed via an event-driven integration model. So your integration needs to periodically scan the data and provide a change log to act upon.
Once you have decided upon your synchronization model, you need to identify which fields you are going to keep synchronized between the two systems. Use the User Object reference page to help with your mapping. You can also download a copy of the following spreadsheet to use for your mapping:
Another consideration is the middleware that provides the "bridge" between 360Alumni and your database. Middleware provides enforcement of business logic such as conversion of the data format or structures. Another example of middleware tasks is adding a layer of protection so bad data or glitches can not create chaos in the destination system.
Examples of middleware include Apiant and Zapier, both integration platforms offering prepackaged middleware "scripts" for thousands of software applications. 360Alumni has integrations with DonorPerfect, Raiser's Edge and Salesforce either already created or in development on these platforms.
360Alumni will guide you in the definition of your business requirements, and either custom-build a new integration or utilize an existing integration to connect your application to 360Alumni. The integration platform provides syncing every five minutes, and an interface where you can see detailed reporting on all data transmissions,
Costs: These integration platforms charge a monthly subscription fee for their service, typically around $100. 360Alumni also offers monthly integration monitoring, maintenance and testing programs to bring you and your team peace of mind. These plans start at $3,000 per year and include the monthly subscription fee for the middleware platform.
One method of integrating your application with 360Alumni is via a polling and synchronization method. This involves checking the database periodically for changes and then updating records accordingly. A polling and sync integration works by running a script that checks for updates and then will update a target based on changes. You can make these integrations two-way by simply applying the business logic you create to both checks.
The following integration example uses a CRM to show how a sync integration can work. Awesome University has a CRM that they use to keep track of their alumni and ensure they can keep track of their donations. They have recently become a partner with 360Alumni and would like to ensure that their alumni database in their CRM and 360Alumni remains in sync. In order to accomplish this they will be setting up a sync with 360Alumni using the "Users" endpoint of the API.
For Awesome University's integration they have determined they want to perform a two way sync with 360Alumni and the contacts in their CRM system. They determined this by finding out the business requirements by talking with stakeholders in their organization. This involved a short series of meetings where they discussed what data they wanted to keep in sync with 360Alumni. They decided upon a two way sync because it would allow them to maintain their alumni directory both organically and still be able to manage it through their CRM.
Awesome University had to decide what parts of their contact data they wanted to keep in sync, so they referred to 360Alumni's field list and settled upon the first name, last name, email, and phone number fields only. They did this because they had only maintained these pieces of contact information in their CRM so they wanted to get them updated as users provided updates. They could have included additional fields but chose a lean approach for phase 1 of their integration.
Awesome University maintains a couple of in house servers so they decided their script will be written in node.js and run once a day at 1 AM on one of their linux environments. Their script will simply look at records that were changed in each system and then update or create records on each of the respective environments. This also allows Awesome University to put in any transformations they need.