var metaMan = MetadataManager.GetManager();
var dynType = metaMan.GetMetaType(typeof(Subscriber));
if (dynType != null)
metaMan = MetadataManager.GetManager();
dynType = metaMan.CreateMetaType(typeof(Subscriber));
var metaField = metaMan.CreateMetafield('Token');
metaField.DBSqlType = "NVARCHAR(150)";
metaField.DBType = "LONGVARCHAR";
metaField.ClrType = "System.String";
After the Sitefinity 5.1 release in which we have introduced the Notifications service the whole way the fields are resolved has changed. We are using the so called SubscriberRequestProxy which handles all the built in fields and displays them properly on the message, but it does not have logic for the custom fields.
The reason for this is that Sitefinity was never designed to be able to display those custom fields, however prior to the 5.1 release the workaround from Boyan Barnev in this forum post was working because Sitefinity was using the standard SMTP way.
We have a PITS feature request logged in the system for this functionality. You can follow its progress and vote to increase its popularity.
So what's the work around for this in latest Sitefinity version. Also I can not find PITS, can you share the link to this issue.
I am running Sitefinity 7.0 and have found a problem, it may be related...
If you add your custom field to Subscriber then send an email there is caching that occurs in the database.
1. if you run this query
You will see your custom field and its values. Note: the custom field doesn't appear to be actually created in the DB until a Subscriber is saved for the 1st time following the change.
2. Next, if you run this query... you'll see that the subscriber info is also stored in another set of tables... AFTER the 1st time they are sent an email. The resolve key value should be the ID of the Subscriber from the 1st query.
FROM sf_notif_subscribers s
JOIN sf_ntf_sbscrbrs_cstm_prperties p
ON p.id = s.id
WHERE s.resolve_key = ''
3. Now if you update your custom field on the Subscriber (sf_subscriber) to any value... the sf_ntf_sbscrbrs_cstm_prperties val is not updated and this is what you see in the email.
My guess in your case is that the sf_ntf_sbscrbrs_cstm_prperties.val is an empty string. Their code example doesn't show how to update this cached value. I'm trying to find a solution now. Simply calling SetValue for the custom field and saving does not appear to work.