CiviCRM Community Forums (archive)

Bit of a challenge, which I do have a solution for but it is a bit hackish....so any more structured alternative is very welcome!

The use case: we have guys out in our neighborhood meeting with our customers and doing all sort of stuff. Part of what they do is triggered from the activities they are assigned in CiviCRM. They receive an email, which they can see on their mobile phones. For example, the back office receives a call from a customer saying he needs someone to come over and inspect leakage in the house. The technical guy receives the email and could go to the customer concerned without getting back to the office. However, it would be a huge improvement if they would also see the address of the customer, which is not in the standard message template.

So I thought I would solve it by changing the standard message template Cases - Send Copy of an Activity. I would have to add a token to hold the address of the customer, which I could do with the token hook. If I then use the tokenValue hook however, I only get the contactId of the assignee id and NOT the id of the customer involved. What I am going to do now is use the API to retrieve all the acitivities of the assignee and assume I need the latest activity, and retrieve the address of the first target.
That will probably work for my specific need, but it is a little hackish.............any better suggestions?
 

And with the ids of the assigned, you can use the smarty {crmAPI} in the mail template I'm quite sure.

1) I'll second (or third) the point about using Smarty and APIv3 instead of the token hooks. It's more flexible and (when there are multiple entities floating around) clearer.

2) When using "Scheduled Reminders" to generate per-activity emails, I encountered a similar issue. I initially tried using {crmAPI} to lookup target/assignee contacts based on the activity_id, but that proved cumbersome. (I needed to do multiple lookups -- and to use the same sequence of lookups in several different email templates). This led to a hack called {simpleActivityContacts}, as in:

{simpleActivityContacts activity_id=$activity.activity_id}
Hello, {$assignee.display_name}, you should talk to {$target.display_name}.

That particular Smarty function probably shouldn't be publicized, but it may be an interesting example.

3) If the activities are managed through CiviCase, you might use client_id in lieu of target_contact_id or activity_id.