Does an update through the web trigger the Ranking SP?

Random question on a late Friday night.  At the moment I can't recall the name of the stored procedure that is triggered on any change to a constituent record.  Its the one intended to update constituent rankings, but is used for other things as well.

 

The question:  Does an update through the web API trigger that procedure as well?  I am working within a consortium environment with a few different website behaviors (including TNEW).  What I'm worried about is that a patron will indicate a preference to not be contacted by <method> (email, phone, etc) and it will be placed on the General Tab contact restrictions.  Since we use attributes to manage these restrictions per organization, that won't work.

So I was envisioning an addition to the ranking procedure which would determine which orgs API user made the update and then add the appropriate attribute and reset the general tab setting (of course, the next time the customer logs in, they will see that preference reverted as well.  But I'll burn that bridge on another day.)

Does this sound workable to anyone else?

  • Former Member
    Former Member $organization

    Hi Levi

    It's LP_CUSTOMER_RANK. It's called from the table update trigger, so there's no reason it wouldn't work exactly the same way for api updates as for others. I think your idea should be quite workable, with the caveat that some updates through the api are only tagged with the generic API user id, rather than the org-specific proxy user id that you set in t_defaults for that org.

    We have a similar issue with one of our partners. We don't use the General Tab restrictions - We've inactivated all the possible values, and changed the screen labels to say 'Not in Use".  But Seymour Centre uses the POP Expresstix product for their website integration, and it insists on setting the General Tab flags for email subscribers

    What we've done is a bit simpler than what you're proposing to do . We've defined a Seymour-specific value for their email subscribe ("SC E-news temp"), which expresstix is able to set, and then we run an overnight job that converts that setting to an attribute (and removes the General Tab field value). The  "SC E-news temp" restriction value is set as inactive, so no-one can accidentally set it manually, but of course the web api ignores that setting.

    Ken

     

  • Thanks Ken.  Simpler is always better. :)  I think we have a ways to go in defining what each organization's communication policies are, (whether it is opt-in or opt-out by default) but its good to know that there are ways to work around those General Tab values.