A better way to handle form letters.

[jdu98a]

I've made several form letter layouts where the user could add variables to pull info from the different recipient's records. Usually this involved creating a button for each variable with the basic script step to add text to the body of the letter such as "". From here there would be a second "body" field that would look for any variables in the text and substitute the correct field data.

However, here is a way to save a lot of work. And get this, it uses a repeating field. As you can see in the layout.jpg I placed a global repeating field in the layout with enough repetitions to hold however many pre-programed variables I wanted to make available. I gave the user access to the fields in browse mode, but do not allow them to change the values. This allows the user to drag and drop the variables into the text of the "Body" field. Lastly, I put a script trigger on the repeating fields set to OnObjectEnter. All that script does is "Go to field [body]". This is done so once the user releases the mouse after the drag they are not stuck still having the repeating field selected.

Now all that is left is to make the substitution field.

I don't claim to be the first person to ever come up with this way but I've at least never seen it before. It saves at least half the work of programing these variables and also makes it easier to add new variables in the future. I hope it helps you too.

Edited December 11, 2009 by Guest

[bcooney]

I like it! Have you seen this CF: http://www.briandunning.com/cf/438

[jdu98a]

I like it! Have you seen this CF: http://www.briandunning.com/cf/438

Well that will certainly make the substitutions easier. If we're not careful we'll just end up removing all the work. Then we'll have to pretend to look busy, ha.

[bcooney]

Then we'd be qualified to do DevCon presentations, lol.

[lawaid]

Hey, just want to add that the use of the Evaluate function in this manner can be a security leak.

Any function entered in the field can be resolved, including all "Get" functions, "Design" functions, as well as any valid expression targeting data.

For this reason, the Substitute function may be a better choice. It's far more cumbersome, but avoids leaving the door open. You can still use your interface, but perform a mass substitute for any of the "custom merge objects" you allow.

Further, you can tailor the names of your merge objects for those times when the true name of the field is too cryptic or too long, or when you don't want to reveal field names to users.

Just a thought, but it doesn't take anything away from your ingenuity! I like the interface, too.

[comment]

Any user with the Advanced version can evaluate any expression (a smart user can do so even with the regular version). So the use of Evaluate() can expose a security problem - but it doesn't create one.