Topic by Kevin Browne
Hello,
I'm building an audit log which will be used to log changes to Contact custom fields to a Custom Object. The script is a Custom Process script, running on the "contact_update" event. However, I'm having an issue with custom field visibility with the Contact $obj that is passed in to my Custom Process script. I did some research and found the following post:
http://communities.rightnow.com/posts/a0352f9e36
According to this thread, custom fields are not available in the Contact $obj unless they were changed in the event that caused the Custom Process to fire. For instance, consider this scenario:
1) Contact has 10 custom fields, all with values set.
2) Contact is opened via the workspace.
3) One custom field is edited and the Contact saved.
4) The "contact_update" event fires the Custom Process and passes in the changed Contact $obj.
WIth this scenario, the only child of $obj->CustomFields->c that has a value will be the one field that was changed. All other children of $obj->CustomFields->c evaluate to NULL.
So...
In my script, I'm getting the metadata for the custom fields on the Contact, looping through them all, and doing a comparison between $obj->prev->CustomFields->c->field_name and $obj->CustomFields->c->field_name. This works, except when the custom field value has been changed to "No Value". This scenario also evaluates to NULL for the changed field.
My question is, if both scenarios evaluate to NULL, how is it possible to determine if a field was unchanged versus it being changed to "No Value"? Is there another way this can be accomplished in a Custom Process script? I tried retrieving the Contact object by doing a Connect\Contact::fetch($obj->ID) but even on that newly retrieved Contact the unchanged custom fields are coming back as NULL inside the Custom Process script.
Oh, and this doesn't appear to be an issue with lazy-loaded object properties, just wanted to throw that out there as well.
Any help would be very much appreciated.
Thanks,
Kevin