TeamDesk Knowledge Base & Support

basenine 6/9/2023 6:43:32 AM

I haven’t done this but perhaps this:
Your contact form cannot be updated directly via a W2record but…you could relate a child record to it that can update the parent record (via a workflow trigger and update action). Place a checkbox field in your contact form called [unsubscribed]…(you can email newsletters to any contact UNTIL this field is checked).
A link to unsubscribe can be included in your newsletter email
This URL goes to another W2record with a simple unsubscribe checkbox (this is the child record). In your URL, you’ll need to include the parent record Id ( see here for what I mean: https://www.teamdesk.net/help/7.3.1.aspx)
When the user navigates to the unsubscribe W2record, it’ll Auto-populate the parent contact reference (you can hide that from view if you want).
When they check “unsubscribe’ and SAVE, the new record will be created.
The workflow rule in the child record will trigger the update action —> unsubscribe to unsubscribe
Now your customer will be excluded from newsletter emails

My apologies if I’ve missed something in the explanation…doing this from my phone without my glasses😬

Pierre 6/9/2023 7:40:03 AM

Hello Jonathan

You could also consider using webhooks:

Option 1: Teamdesk webhook
You create a (get) webhook in Teamdesk
In the https call, you pass inthe parameter the number of the contact (ie ?contact=1234)
In the TeamDesk table associated to the webhook, you create a trigger which will change the contact 1234 email status
See: https://www.teamdesk.net/blog/whats-new/get-method-with-webhooks/
Problem:
As far as I know, TeamDesk does not allow to redirect the user to a third party site
So when the enduser will click on the link, he will see a blank page saying "accepted" / no confirmation that he will be inscribed

Option 2: Make webhook
This require you to take a subscription to make.com (formerly integromat)
you create a webhook there
Your webhook will fork to two actions:
a) one redirecting the user to a page saying he has been unsubscribed
b) one changing the status of your contact in Teamdesk (either via a webhook, or via a REST API call)

hope this helps

cooper collier  6/9/2023 12:03:39 PM

good day Jonathan.

My two friends above both have valid approaches to your issue. I have a couple more possible ways for you to make this happen and a stupid comment.

To start, there is absolutely no way to make an unsubscribe link that will include the persons record, so all they need to do is click the link and unsubscribe. The person will need to enter there email address to unsubscribe.

OPTION 1 (super easy)

Make 2 tables...

Table 1 is subscriptions. You can capture whatever information you need, but make sure the email address is there and that it is unique.

Table 2 is unsubscribed. This one is simply email addresses.

Make a many many join between the tables and do a summary lookup, and count records matched on email address. If there is a match then you do not use that email address anymore.

Now you display table 1 for subscribing, and email a link to table 2 to unsubscribe. People just need to enter their email address.

Problem! This will NOT meet Euro Gddpr (whatever) rules.... You can set a daily action to delete records above. that may work.


OPTION 2

You have one table that has the subscriber info in it.
Next you make a search view, this view can be set to find email addresses. or email address and last name. Then you display this view on an HTML page, either using a JS embed or a html embed.

To unsubscribe the user goes to this pages, enters email and search, then delete record. Tada!

This has the issue than anyone can find out if someone else is subscribed to your email by simply searching on the unsubscribe page.

NOW for the unhappy comment. I really really hate it when someone asks, "how do I do...." and some idiot answers, "you should not..." or "get Linux" But in this case, I think it's important to warn you about the email issues before you get too deep.

Are you using team desk to actually email the newsletter? If so, you really should not. You are going to have huge deliverability issues. The mail system in Teamdesk is designed for sending to small groups of members. Even then, we have to constantly fight with reports and other messages being marked as spam. If you do wish to send from Teamdesk, you should go through a service like Mailgun.

Plus, if you're in Europe, you need to consider the GDppr rules. Newsletter services have established processes to comply with GDppr rules and any other rules. If you use Teamdesk, you need to program to conform to all the rules yourself. I refuse to do it for my clients. It's just too easy to miss something.

But if you do use Teamdesk to manage your subscription base you now have 5 ways to do it..

Wait.... how about 6... you can get the external user's package and work with it.
Good Luck!!

Jonathan Gee 6/14/2023 6:41:12 AM

Hi Guys,
Thanks for your replies... and I will get to them shortly. I am currently dying from man flu and running a 41degree temperature at the moment.
I just didn't want to think I was blanking the effort you placed in replying with such detail.

Cheers Folks.

basenine 6/14/2023 7:14:02 AM

Cheers for the update Jonathon.
Hope you get better soon…at least by the weekend 👍😬

Let us know how you get on

Scott Miller 6/15/2023 4:18:36 AM

Just adding my two pence/cents re the email delivery piece Cooper mentioned.

The EU Servers utilise SendGrid as the email delivery service and as part of the setup you have to authenticate the customer domain which requires the Customer to update their DNS records. This should alleviate any issues with emails landing in junk or being quarantined. I'm also working on the basis that with SendGrid you could possibly email the masses as that's what others use this service for but don't quote me on this!

Also re the US Servers you can help with the email delivery by a similar process as mentioned above by asking the customer to update their DNS records specifically the customer would add/update their SPF record for the customer domain to designate smtp.teamdesk.net as an authorised mail server. TeamDesk support can advise on this and support.

We always perform the above steps if a customer is emailing from TD :-)

Nick Kemp 7/4/2023 6:46:46 PM

Just to chip in my 2c on Pierre's suggestions. We use an intermediate table, that is independent from our "lead" or "customer" records.

We then use a web-form on this table to allow the end user to self-service. The only difference here is we use a hashed version of primary key of the customer or lead record to relate the web-form to the relevant user record. This allows us, using a relation, to populate the existing customer details into the form without allowing a third party to arbitrarily go through our user list, or just randomly unsub someones address that they shouldn't. Especially important if you are using the default autonumber for your key sequence. You can build on this to provide self service of their subscription/stored data.

The hashed value is passed to the form using a url param in the embed.

It also removes the step of having to get them to search for their own record. Of course you could achieve something similar with a URL param of their email address, but we like the hash method as it prevents unwanted behaviour.

Our use case is specific, we have a marketing platform for a vertical. I would probably off-load this to sendgrid, mailerlite or something similar and just use API calls. Let them handle the unsub etc. For us, it makes sense to keep this stuff in house due to our product.