User Account Placeholders

[Mark]

Hi Ben,

I understand from the help pop-up that;

"These placeholders have limited availability. They may be used in email templates sent only to the admin and client accounts. If they are used in emails sent to to other people (e.g. users: the people who submitted the form), they will appear blank".

Is there any method to output such fields (e.g. {$FIRSTNAME} / {$LASTNAME} / {$COMPANYNAME} / {$EMAIL}) to Email templates sent to external addresses?

Alternatively, is it possible to pull the First & Last Name from the user logged into FormTools and insert them into cells defined in a form? (e.g. They are automatically populated - similar to the 'Last modified' field)

- Mark

[Ben]

Ack! Sorry Mark, I totally missed this post. (And I still owe you an email regarding your account + license for the Custom Fields modules... boy, I'm slippin'!).

Is there any method to output such fields (e.g. {$FIRSTNAME} / {$LASTNAME} / {$COMPANYNAME} / {$EMAIL}) to Email templates sent to external addresses?

Good question. Yes there should be. I'm pretty sure 2.0.6 permitted this and so should 2.1.0. I'll look at this today to confirm.

- Ben

[Ben]

Hey Mark,

Yeah, you're totally right. This is missing in the current Beta - I'll fix it in the next release. Thanks for the heads up!

- Ben

[Ben]

Hey Mark,

So I was looking into this tonight and now I'm leaning towards the opposite direction: remove those client account placeholders altogether.

Here's the thing: the feature doesn't really make sense - it never did with the Form Tools design. In the past, I've explained it like so: "those placeholders ({$FIRSTNAME}, {$LASTNAME}, {$EMAIL} and {$COMPANYNAME}) will be converted to the appropriate value if the email is sent to a client account."

It sounds like that makes sense, but actually it doesn't. Email templates with Form Tools 2 are designed to permit multiple recipients - the main recipient, multiple cc's and multiple bcc's. So what happens if you target multiple client accounts as ccs or bccs? What value would get those placeholders? Presumably the only logical solution would be to have those placeholders be evaluated if the MAIN recipient is a client account - but then, why not hardcode it? The name would never change; the only benefit would be in case the email itself changes, but does that need to be in the email content itself...?

Frankly, it seems very complicated for such a minor feature, and offers very little value.

You convinced? Disagree? Anybody? I'm going to wait a few days, but unless I hear a convincing counter-argument I think I'm going to drop the feature.

All the best!

- Ben

[Mark]

Hi Ben,

Sorry about the delay in getting back to you.

I'm gutted to read that the Account Placeholder feature has been completely dropped! As a result we're having to patch the '2.1.0-beta-20110731' with the feature from when it was available in previous Beta releases.

Allow me to explain why the feature was so useful to us...

We use FormTools purely internally to compliment our Call Logging system on the IT Helpdesk. When calls have to be passed to third-parties via Email, each Analyst constructs the Email differently (fonts, sizes, styles, different data etc.) I wanted to make our communication to third-parties consistent regardless of which colleague actions the job ticket.

In short, the Account Placeholder feature allows us to automatically generate our Email signatures. The third party and the end customer (who also gets a copy) receives the Email as if it was personally constructed and sent from Microsoft Outlook etc. In fact, by defining an additional recipient within the FormTools form setup and then adding a Filtering Rule into Outlook, form submissions sent out externally would actually appear then appear in our Mailbox Sent Items folder! Neat!

For example:

----------------------------------------------------------------------------

New Call To Log: Complete Plumbing Services

Please can we log the following call with you?

Call Ref: XT235771
Customer: Complete Plumbing Services
Job Description:
etc.......
etc.......

Kind regards,

John Smith
Support Analyst, IT Helpdesk

T: 01234 567892
E: john.smith@company-name.com.uk

Company-Name
Unit 3A, Westfield Business Park
Coverdown
Southants
SU22 3RL

Please consider the enviroment - do you really need to print this Email?

----------------------------------------------------------------------------

Or in Email Template form:

------------------------------------------------------------------

Kind regards,

{$FIRSTNAME} {$LASTNAME}
{$COMPANYNAME}

T: +44 1234 567892
E: {$EMAIL}

Company-Name
Unit 3A, Westfield Business Park
Coverdown
Southants
SU22 3RL

Please consider the enviroment - do you really need to print this Email?

------------------------------------------------------------------

Note we use the COMPANYNAME field in the account profile as the Job Title and Department.

I hope this makes sense and is a good enough reason for you to perhaps re-consider the feature :-)

All the best,

- Mark

Hey Mark,

So I was looking into this tonight and now I'm leaning towards the opposite direction: remove those client account placeholders altogether.

Here's the thing: the feature doesn't really make sense - it never did with the Form Tools design. In the past, I've explained it like so: "those placeholders ({$FIRSTNAME}, {$LASTNAME}, {$EMAIL} and {$COMPANYNAME}) will be converted to the appropriate value if the email is sent to a client account."

It sounds like that makes sense, but actually it doesn't. Email templates with Form Tools 2 are designed to permit multiple recipients - the main recipient, multiple cc's and multiple bcc's. So what happens if you target multiple client accounts as ccs or bccs? What value would get those placeholders? Presumably the only logical solution would be to have those placeholders be evaluated if the MAIN recipient is a client account - but then, why not hardcode it? The name would never change; the only benefit would be in case the email itself changes, but does that need to be in the email content itself...?

Frankly, it seems very complicated for such a minor feature, and offers very little value.

You convinced? Disagree? Anybody? I'm going to wait a few days, but unless I hear a convincing counter-argument I think I'm going to drop the feature.

All the best!

- Ben

[Ben]

Hey Mark,

I do wish we had talked sooner, however I still don't think the feature makes sense as it was - or maybe I'm just not understanding something.

Let me try to explain why it doesn't make sense to me.

Here's a scenario. Imagine an email template that's sent to these people:
- the person who submitted the form
- client #1 (cc)
- client #2 (cc)

Since this is a single email template, the content of the email will be the same, as it's sent to all of them at the same time. So in this scenario, if the email content included a user placeholder, what values would actually end up in the email? Values from client #1 or #2?

Neither really makes sense.

The ONLY circumstance in which those user placeholders would have made sense would have been if the email template contained only a single client account (either as the main recipient, cc, bcc, "from" or "reply-to"). In that case, I could get the code to figure out what values to use. But, in that scenario, the placeholders would become redundant: the person constructing the email template would have known who'd be the client that was relevant to the email template (since they'd have just specified them) and they could just enter in the information manually. [True, the placeholders would have had the benefit of being automatically updated as their account updated, but I still think it would raise confusion about when those placeholders could be used and when not.]

See what I mean?

Let's get to the bottom of this. This is one of the very few times I've dropped functionality, and I hate to do it.

- Ben

[Mark]

Hi Ben,

Yes I agree I'm sorry we didn't talk sooner! (my bad!)

There is one form design per Third Party company depending on the information they require for logging a new job, as each companies requirements vary.

In our scenario, it's always us that creates the ticket/submission within FormTools (e.g. We login to FormTools and submit the form internally). The job details Email is then fired off to the Third Party hardware company, with a copy being sent back to us (to be filtered by Outlook into the Sent Items folder) and another to the client if they require one.

The Email signature is built depending on who (our analysts) logs into FormTools and creates the ticket/submission. I'm a big believer in personal service, so it's always been my preference to sign off Emails with an individuals signature rather than "Many thanks, IT Helpdesk".

Hope that makes sense,

- Mark

[Ben]

Hi Mark,

Sorry for the wait - I'm off traveling again (NY this time - boy it's hot!) so I'm playing catch-up in the forums.

So! I *still* think there's a problem with the design. I see why you need it, totally - but I really can't add it back in as it was because it wouldn't make sense when considering the functionality as a whole.

Let me do my best to explain.

In your scenario, you have the placeholders being filled by whomever happens to be logged in - so you can have a single email template which sends different content depending on the client account info. Nice! That makes total sense now - thanks for the explanation. And I can totally see why that would be useful.

However, say I were to add back in the user placeholders back into the email template as before: then they would only make sense in certain contexts. Namely: when the user was logged in. For regular form submissions, those placeholders wouldn't be filled. For the administrator sending an email with that template, they'd be empty.

I really want to avoid "weirdnesses" like that, that are unintuitive and would require the documentation to make sense of it. If I were to use those placeholders, I could very much see myself forgetting

Frankly, I just don't like it...!

So how about an alternative solution. Have you stumbled across this page at all?
http://modules.formtools.org/hooks_manag...laceholder

One of the many things the Hooks Manager lets you do is add in arbitrary placeholders to be used in your email templates. What if you could define a Hook Manager rule that would always insert a {$signature} placeholder that would contain the appropriate data? One additional benefit would be that the signature placeholder could be used in multiple email templates so you wouldn't need to re-define it should you use multiple email templates that need it.

Would that be an adequate workaround, do you think?

I wouldn't bother looking too much into the module yet - I need to do a little legwork to confirm it would all work. But if it didn't, I'd make it.

- Ben

[Mark]

Hi Ben,

Thank's for the reply - I have never tried the Hooks Manager module, browsing over the documentation it certainly looks like a powerful tool when configured and would save A LOT of time with these Email templates!

I'll wait for the official 2.1.0 release before doing any more testing and will let you know how I get on. Sorry to hear about your Mac Book - cheeky cats!

- Mark

[Ben]

haha, thanks. Going without internet for 2 hours led me to the Mac Store where I splurged on a nice new Macbook Air. It's *wonderful*, so I can't resent the cat too much.

And great, sounds good. I'm sure I can get it working with the Hooks Manager instead though.

Speak soon -

Ben