Wrong Problem?
First, I’ll give what I believe is the solution to the wrong problem. That solution is the same as for the Default UI Element question: a default command button. Such a button replaces everything in the text box with the default content, whether the user changed static content, computed content, or both. In the process, the placeholders for the computed content reappear because such placeholders are part of the default content.
This still applies if only the placeholder text is editable. The default button still sets the content to default, which still comes down to setting all the content (placeholder or not) back to what it was at the beginning (with placeholders).
However, I sense you really want something different. You want to revert only the changes to the placeholder content, like the contact’s name and invite type, while other changes (such changing “Hello” to “Dear”) are unaffected. Now you have some problems if you try handle it with any kind of single sweeping “default” control.
What if the user deleted the placeholder entirely? Can the system still tell where to re-insert the placeholder where the user wants it to be? The user may have moved or edited all the text around where it used to be.
What if the user changed the placeholder to static text, but then moved the static text? Does the placeholder get reinserted where it used to be, or where the static text is now? The user may be expecting either, depending on the semantics of the edits. What if the user moved part of the static text?
What’s to stop users from changing the placeholder to something completely unrelated to its original meaning (e.g., change “free lunch” to “replying to my email,” having changed the prior text to “Thanks for”), so that reverting to the placeholder no longer makes sense?
What if the user wants to revert one static string to a placeholder so it gets updated (e.g., Contact_Name), but not the others?
Right Problem?
It seems to me that if the users’ tasks call for such detailed control of the content where they revert changes to placeholders, but not changes to static text, then they probably need a general ability to:
Delete any arbitrary placeholder
Insert the placeholder that was just deleted
Insert any arbitrary placeholder a second time
Move a placeholder to a new place
Replace any placeholder with static text.
In other words, you basically need a template editing feature, where user can manipulate the placeholders as objects:
A toolbar across the top allows the users to insert any placeholder anywhere any number of times. Placeholders in Subject and Body text boxes may be selected, moved (e.g., by cut-and-paste), and deleted (e.g., with the delete or backspace key). You can also give each placeholder an “x” to click to delete the placeholder, but only if usability testing indicates it’s necessary.
Users cannot edit individual characters in the placeholder content. If the user clicks anywhere on the placeholder, the whole placeholder is selected for action. The user can then type something, and that (static) text replaces the placeholder, like selecting and typing usually does in a text box. Users revert replaced and deleted placeholders by clicking the desired Insert toolbar control with the cursor in the desired location in the text box.
The page/window can open with default content in the text boxes, including placeholders. You can still have a Default command button to revert the whole thing, but I suspect you actually don’t need or want such a wrecking ball (although incremental Undo is a good idea).
It is necessary to visually distinguish placeholders from static text to help user understand why they behave differently. Graphically go with something to suggest each placeholder is a single atomic object, not a string of characters. However, you may want to provide a means to “preview” the email, displaying to the user exactly how it will appear to the receiver with the placeholders showing their content in their final format.
The General Problem
You may want to provide a means to edit the content of a toolbar control, so the user can override, for this one email, any placeholder content for all its locations in the text boxes. In this way, I’m circling back to your question at a general level, but not for the specific UI you propose.
Yes, for a given placeholder (or any individual field), I expect it would make sense to users to represent the source of the content as a state, but it probably should be an explicit state for each placeholder, not globally for all placeholders. The exact name for the states depends on your application, and probably should be something more specific than “default” or not. I expect users may understand default values, but don't anticipate the default referring to the source of the values.
In this example, let’s say a given placeholder content (wherever it occurs in a letter, however many times it occurs) can be set manually for the current letter or by linking it to a database feature known to users as “the profiles.” This binary alternative could be controlled with a “stateful” or attribute control such as a checkbox or toggle button. However, I think you may make the behavior clearer to the user if you use a control that explicitly presents both possible states. Radio buttons or maybe even a two-value dropdown would be okay for this, but a switch control may be best:
When the user switches to Overridden, the text for the placeholder become editable so the user can set it to any desired content. This has the advantage in that the computed/custom state is explicit and separate from the placeholder content. In addition to making the behavior clearer, this gives users the option to switch to Overridden to “lock” the placeholder at the current value so it doesn’t update. They don’t have to edit the content to break the link with the Profiles.
Switching to From Profiles reverts the text to computed. This may change the text, which, yes, is not typical behavior, but I don’t think users will have a problem with that, especially if the system remembers the custom value and reverts the content to it if the user switches back to Overridden (a simple form of undo). Then the control just changes what the user sees and uses (a Profiles value or an email-specific value), not what the value actually is in either source.
This UI to change placeholder sources could be on the email page/window itself if it’s fairly common to customize placeholders. Otherwise, it may be set on a linking page or dialog.
