DESCRIPTION:
Empty CRM data fields, including Advanced CRM Group fields assigned to the CRM, do not allow updating once the contact becomes a ‘Member’ (ie: is a Secure Zone subscriber/has a password).
BACKGROUND:
If a regular user (non-member) fills out web forms on the front end of a website (using the same email address), their details will be updated as per the last form submission made.
Eg:
If they first submitted their name as ‘Joanne’ but then submitted another form with their name as ‘Jo’, then the CRM Record will show their name now as ‘Jo’.
Inversely, if that user is a Member/Secure Zone subscriber, their CRM data will be locked from such updates (unless specifically using the ‘Update Account Form’ when logged in).
PROBLEM:
While the above setup is good for security and prevents unauthorised changes of Member details, having the same security on ‘empty’ fields makes it hard to collect and store additional or new data against a user.
So, any general interactions the Member has with forms on the site when collecting different CRM information, will not be stored against the user in the CRM - even if logged in (the data is only captured in the specific Case file of that form submission).
POSSIBLE SOLUTIONS:
Perhaps the system can distinguish between an ‘empty’ field value (one that has been submitted via a Form as a purposely empty value) as opposed to a ‘null’ field value (that only exists in the CRM and has never ‘received’ submission data [empty or otherwise] to it).
Then, if the value of the field is ‘null’ it CAN be updated from the front end whether it’s a contact or a member submitting the form. But if the value of the field is ‘empty’ or has data (not ‘null’) it honours the current security protocol and can not be updated for Member records.
Alternatively, if this poses a security problem or backward compatibility issue, perhaps we can have a system setting that we can enable to allow empty fields to be updated from the front end for Member records. So we can make that choice on a per-site basis.
Or maybe it’s a setting added to the Form itself (or even per field), so the ‘override’ can be controlled on a more granular basis and not system-wide.
