• Replies 6 replies
  • Subscribers 336 subscribers
  • Views 160 views
  • Users 0 members are here
Related

Potentially Important Considerations Around Contact Permissions

Gawain Lavers
$organization

I am nearing the point of finally moving our (ancient) organization to the proper use of Contact Permissions.  I'm pretty happy about our planning and design, user-facing options, etc.  However, in updating some of our customizations, I've uncovered a couple of very strange features of Contact Permissions that I thought I should share, since they were not clear to me when we started the process.

The first is technically in the documentation, but I could have easily read this paragraph many times and simply skipped past it because it didn't scan:

All non-presenter types in a category share an Updated On date, while each presenter type has a separate Updated On date. Clicking the Today button sets the Updated On value to the current date, which allows you to record renewed permissions if the permission responses haven't changed. Changing the response for a contact permission type also automatically sets the Updated On date to the current date.

Okay, what this means (or what happens, in any event) is that if you update a Contact Permission, every other Contact Permission Type in the same Contact Permission Category will have both its "Last Asked" date and "Last Updated Date/By" (TX_CUST_CONTACT_PERM_TYPE.last_update_dt, .last_update_by) updated at the same time.  I do not know (nor is it written) what the use-case is for this, perhaps GDPR only requires to you ask about one permission to consider all permissions updated?  We're not affected by GDPR, so we don't much care about that, but the fact that I can't use the audit columns effectively track changes to individual Contact Permission Types is very worrisome to me.

The second item is of much graver concern: adding/updating/deleting (I'm not sure if there is actually a deletion option in the client?) a Contact Permission Type does not trigger an update to T_CUSTOMER.last_activity_dt, and does not trigger a ranking update (AP_CUSTOMER_RANK, LP_CUSTOMER_RANK).  This is a huge issue to us, as some of our Contact Permissions need to change a customer ranking.

I'm holding out hope that this is some previously unnoticed defect (I have a ticket in to that effect), but if not I'll have to commit to some kind of drastic workaround.

Parents
  • $organization

    This is in the "plug in that became a v16 feature"? It's been a while since I did the mapping of Contact Permissions Categories and dropped he implementation when we heard it was free with v16.

    • That's odd. From discussions precovid folks were looking at various categories being Philanthropy, Mkting etc and indiv Permissons being the mail/ email /SMS. So I assume that updating one permission on a linked category in that sense would make some sense.  However,  talking with the network more recently the recommend was using CP as a global which could get annoying.
    • I'm assuming that means either schedule a nightly job or maintaining a local trigger on a system table.

    Thanks for the heads up.  This is recently back on my planning radar

Reply
  • $organization

    This is in the "plug in that became a v16 feature"? It's been a while since I did the mapping of Contact Permissions Categories and dropped he implementation when we heard it was free with v16.

    • That's odd. From discussions precovid folks were looking at various categories being Philanthropy, Mkting etc and indiv Permissons being the mail/ email /SMS. So I assume that updating one permission on a linked category in that sense would make some sense.  However,  talking with the network more recently the recommend was using CP as a global which could get annoying.
    • I'm assuming that means either schedule a nightly job or maintaining a local trigger on a system table.

    Thanks for the heads up.  This is recently back on my planning radar

Children