URL that automatically creates a CSI?

Hi Nicholas -

We've toyed with the idea of doing some sort of auto links from an email, but for us found that we wanted to gather more info than just a yes/no (e.g. number of tickets, HABO name).

However, when we *were* looking at it we thought of doing a link to a web form that would basically feed the info needed in a link - such as customer number and yes/no status. The form could then process that info and do whatever you want it to do, whether it be generate a form email and confirmation email, make a CSI in Tessi, etc.

So it's totally doable, we just ended up not going that route because we wanted to ask/offer additional information that was best collected via an rsvp form rather than a one-click button.

- Heather

Hi Heather,

Thanks for sharing, it's great to hear that I'm not completely out of the realm of possibilities!

Could you share how far you got with the CSI creation step?

If we can get over that hurdle, I'm sure the other details could be worked out.

Cheers,

Nicholas

Hi Nicholas

Possible, although it might need a bit of a workaround.

I use the API call ExecuteLocalProcedure to do a number of things on email clickthrough pages.

For example, unsubscribing their email; in this case the link in the email contains a querystring with the customer number and the data protection list number. I use ExecuteLocalProcedure to pass these to a stored procedure that either amends their existing data protection record for that list, or creates a new one with an opt-out for that list.

I use AddCustomerServiceIssue to add a CSI for a number of reasons. You can add any additional data in the notes.

However, AddCustomerServiceIssue requires a valid session key, and associates the CSI with the customer associated with that session key; in plain English, meaning that it only works if the customer is logged in. Obviously this isn't good enough if you want a CSI to be added instantly when the customer clicks a link. I suppose you could make a page that temporarily logs the customer in, adds the CSI then logs out, but it wouldn't be good practice (and I think the login call requires the password or more personal detail, which you wouldn't want to send in the email querystring)

So there's two ways round: You can link to a login page that redirects to the CSI-adding page once logged in (this also assures you that the CSI has been applied to the correct constituent record, rather than for example a wife reading a husband's email and clicking on the link?).

Or you could set up a simple stored procedure that takes the customer number and any other information you want to record, and adds a line to T_CUST_ACTIVITY. This seems like the simplest solution to me, as long as you run the stored procedure past the Tessitura helpdesk to make sure the data you're putting in is always valid.

Sorry, that ended up a little rambling - hope it was useful.

Hi Ian,

Thanks for sharing your experiences, and the tips.

Theoretically, can you think of anything to create a CSI using a similar procedure to your unsubscribe link?

Also, my colleagues would be very interested in glimpsing the back end of how you create the unsubscribe link without requiring the customer logging in. 

Best,

Nicholas

Hi Nicholas,

For unsubscribing, in the past I have seen a url with the customer number used.  So when the email was sent out the url was generated with the customer number in it.   Also some flag was passed in as well to signify what they were unsubscribing from.

Jon

Hi Jon,

That sounds very nifty. Do you have an example of this URL?

Having a simple unsubscribe method is something that is a challenge at the moment.

I am resisting having a simple 'login to manage your account and unsubscribe'. This seems customer hostile to me.

Cheers,

Nicholas

Sure,   The url went    domain/unsubscribe.aspx?c=2187966&t=1 .  The "c" in the url was the customer number and the "t" was the type of mailing to unsubscribe from.   Then there was a call to the webapi executelocalprocedure to call a a proc to unsubscribe them correctly.

That sounds great Jon.

Can I ask how you handled the need for the local proc to have a sessionKey?

I'm thinking the email link brings you to a landing page, and the code on that landing page first calls GetNewSessionKey and then calls the local proc to unsubscribe/or say yes/no to an invite?

Also, did you see any potential for this to be hacked by others manually changing the customer number in the query string? 

thanks,

Dara

The script will need a SessionKey, yes; I call GetNewSessionKey in global.asax under Session_Start, so that whatever page the client lands on, they'll be given a SessionKey.

Then call ExecuteLocalProc to do the unsubscribe/CSI gubbins depending on your localisation.

Yes, there's the potential for manually changing the query string; the key here is to strictly limit what your local procedure can do, validate the data to stop SQL injection, and do not display any customer data that is not already given. For example ours can take customer number or email address, but does not display the unsubscribed email address if the customer number is given. For more extensive validation you could require a correct email address AND customer number.

ExecuteLocalProc should be used carefully as it does not require a customer to be logged in to the session. Most other API calls do.

The script will need a SessionKey, yes; I call GetNewSessionKey in global.asax under Session_Start, so that whatever page the client lands on, they'll be given a SessionKey.

Then call ExecuteLocalProc to do the unsubscribe/CSI gubbins depending on your localisation.

Yes, there's the potential for manually changing the query string; the key here is to strictly limit what your local procedure can do, validate the data to stop SQL injection, and do not display any customer data that is not already given. For example ours can take customer number or email address, but does not display the unsubscribed email address if the customer number is given. For more extensive validation you could require a correct email address AND customer number.

ExecuteLocalProc should be used carefully as it does not require a customer to be logged in to the session. Most other API calls do.

Hi Ian,

That sounds like a very elegant solution. Are you able to share your LP or aspx file? It would be fascinating and instructuve to see the plumbing behind this.

Cheers,

Nicholas