Advance Donor Management Software

Hello Tessitura Users,

We are in the beginning stages of initiating data sharing with our Campus' donor management system, Advance, but there are some concerns due to the fact that we're on a hosted solution.  Has anyone else on a hosted solution successfully done this type of data sharing with Advance?

Thank you!

Mandy

Parents
  • We have (Cal Performances at UC Berkeley).  What I consider the balance of the work has been borne by UDAR, since they have the larger pool of developers (i.e. > 1).  We are in the middle of a multi-stage project to share information in both directions, with Phase 1 in operation and me scrambling to get Phase 2 going.

    Phase 1 was really the most important.  Since the UC Advance db was the system of record for all campus contributions, our Transaction Processor was having to dual enter everything: first entering and processing the gift into Tessitura, then entering the gift details in "CADS", then coming back from CADS with UC financial and customer codes to enter into custom fields in Tessitura.  Phase 1 was the automation of that process.  My part was simply to pull together all of the pieces of information UDAR needed for each gift/pledge/pledge payment and then hand it to them for processing.  This I did by creating a Custom/Execute endpoint with the REST API that they could access.  They can run the endpoint passing in a few parameters (such as transaction start and end dates) and I send back the transactions with added biographical and financial information.  Currently we are expected to have flagged customers in our database with correct ids for the customer accounts in CADS, or to create them in in CADS manually if they are missing.

    Phase 2 is pulling back limited bio data from CADS that we lack or have a hard time keeping up with in Tessitura.  In this case I've created a Custom/ "Data Service" endpoint (or set of endpoints, actually) that correspond to custom staging tables in Tessitura.  UDAR can then use these to enter data into the tables, and then it is on me to have procedures (currently in process) to review and then import the various bits of data into the appropriate places in Tessitura.

    We are a RAMP client (like, I expect, you) and the only ramifications of that were getting the appropriate server IPs from UDAR and having RAMP whitelist them for API access.

  • Hi Gawain,

    Thank you so much for you response - this is very helpful!  Did Berkeley run into any contractual or data security issues between RAMP and the campus regarding access in either direction?

    Thanks!

    Mandy

  • Since we were manually moving the data back and forth before it wasn't technically a request for new access on either side.  However, discussing which servers would be allowed access to our Live and Test API servers was important, along with carefully controlling the permissions granted to the service user account that we created for them to use.  It's important for anyone who has access to your API servers, especially as the REST API grows in functionality, to understand that they are adding to your "threat surface" for PCI-DSS considerations.

Reply
  • Since we were manually moving the data back and forth before it wasn't technically a request for new access on either side.  However, discussing which servers would be allowed access to our Live and Test API servers was important, along with carefully controlling the permissions granted to the service user account that we created for them to use.  It's important for anyone who has access to your API servers, especially as the REST API grows in functionality, to understand that they are adding to your "threat surface" for PCI-DSS considerations.

Children
No Data