Can someone just confirm that I can't use solicit code as my conditional field in a donor acknowledgement conditional mail merge? It seems ridiculous to me that I should have to add a do not solicit attribute to everyone with the do not solicit solicit code in order to send out seperate thank you letters.  The reason I want to do this is that we have a blurb on all of our thank you letters for memorials, events, etc. that has an option to opt-out of future mailings from us (which I hate b/c we are not even legally allowed to solicit any of these people so having them opt out is pointless).  If they have previously opted out I would like to send them a different thank you letter that says we have recorded their preference and they do not need to opt out again. 

Basically I want 2 thank you letters - one for the majority of people with the standard blurb and one for people who have opted out previously and as such are marked with a special solicit code.

I think the only way to do what I want is to globally add an attribute of do not solicit to everyone with this solicit code. Can anyone see a better way to run this conditional thank you letter?

 Thanks!

You don't need to use it as a conditional merge field - it (Solicit Code) is offered as a standard filter in the MAIL functionality.

The only thing you would do is on your normal Donor Acknowledgement letter or receipt  use a Filter on Solicit Code to Exclude selected.

To get the ones with the code I would use a Query in the Include are that says solicit code equal to your special solicit code and make sure the solicit code filter is set to include all.

He wants to use it as a conditional merge field and I agree that he should be able to.  He wants to add language to the letter that tells the donor what their recorded preferences are (solicit codes) so they do not need to ask again.  To do this he needs it as an available field either to do the condition in RE Mail or to even do it using MS Word.

I personally have completely abandoned using solicit codes and always use attributes anyway.  I prefer to have the dates and comments and I also prefer to be able to exclude them in Mail using the attribute tab.  You may want to consider this change so you have more flexibility in Mail without duplication of effort.

Ok I see - I was trying to make a work around using mail since it is not a field offered in 'fields to include' I can see where attributes might work more effectively in some cases.

And your work around would work but it would require him to always run two separate mail runs - one using a query of those with the solicit code and one for those without.  That would get on my nerves as a daily process but temporarily it would work.

To get started, create an attribute in Configuration, Attributes, that will hold the value of the solicit code in the attribute field.

Next, create and save separate queries for records with the specific solicit codes.

Finally, use the instructions in the knowledgebase solution to globally add an attribute to the records designating the solicit code value.

Actually the final step would be deleting the solicit codes once you have confirmed that the attributes have all been added properly.  I do not recommend maintaining duplicate systems so I would completely remove the solicit codes and even delete the values from the solicit codes table so they can't accidentally be added in the wrong place.

Thanks everyone - I guess I'll be moving everything to an attribute so I can avoid having to run 2 different merges (that would get on my nerves too!) For some reason I always forget or avoid attributes because we use them almost solely to maintain information about our clients not our donors (sometimes these overlap though) and I don't handle any of that data entry