I've successfully set up a Zap to process new emails matching a given search in my Gmail account (extracting info and adding it to a Google Sheet). But I'd like to make it process the 145 existing matching emails already archived in my Gmail as well. Is there a way to accomplish this?
David here, from the Zapier Platform team. Unfortunately, Zapier is built around doing ongoing work, not a single task. Polling is specifically designed to only process new things after the zap has been turned on. So, you'll have to cheat a bit.
For the purposes of your backlog you could set the gmail filter to look for what it's set to now, plus a label (say, zapier-backlog). If you do the search right now, it should be empty (and a poll on the zap with that search shouldn't return anything). After you turn the zap on, add that label to all emails you want processed, and the'll show up as "new" to the zap and all get processed accordingly.
Once that's done, you'll want to remove those changes and only have it process new emails. Hope this helps. Let me know if you've got any other questions!
Related
I have a rails app with sendgrid API setup and I can send transactional emails just fine. Now I want to be able to send newsletters but I'm a bit confused about the flow and how to keep track of which users want to unsubscribe from the newsletter.
The way I was considering doing this is when a use signsup to automatically send a request to the SendGrid API and add them to the contacts list, and if they want to unsubscribe from the newsletter or transactional emails from my app's settings page I can save this info in my app's DB but also send a request to sendgrid's unsubscribe list to change the value there too. Now I can create a newsletter in sendgrid and send it out from there without having to do anything within my app. One caveat to this approach would be if the users clicks the unsubscribe button via the newsletter and the value gets changed in sendgrid but the change won't be reflected in my app - To work around this would it be better to create a cron job that periodically checks sendgrid for any changes and then save them to my DB, or should the unsubscribe page be part of my app, and when they select unsubscribe I save it to my DB and then push the changes to sendgrid? If i do this approach, would I require users to sign in if they want to make these changes?
An alternative approach would be to forego creating any contact lists in sendgrid and just create the email in sendgrid and sent it out using a rake tasks to trigger the sending?
Apologies if this is a very basic question, but this is my first time trying to setup newsletters etc and can't seem to find anything online about the best strategy to take in order to do this - I hope this question makes sense.
Twilio SendGrid developer evangelist here.
This question is a little too opinion based for Stack Overflow, many of the options you describe will work but they rely on whether it's the right decision for your application. But, I will try to give some guidance.
First, however you approach this, I would recommend you set up subuser accounts within SendGrid so that your transactional and newsletter emails come from different subusers. This way unsubscribes from newsletters won't affect transactional emails.
I would use the SendGrid contacts list to send out newsletters. This gives you a lot of power over your contacts without you having to build things yourself. You can segment your lists, create unsubscribe groups (where a user can unsubscribe from a subset of your emails instead of all of them) and send emails from within SendGrid without bothering your Rails app. You can still set up to trigger a newsletter from your app using the API if you want to.
As for maintaining the user's subscription status, I would go with exporting the contact lists and keeping your database up to date that way. The important thing when sending to your contact list is that SendGrid has the source of truth for subscription status and your application can be a bit behind if it needs to be. The SendGrid docs for exporting contacts also say:
Twilio SendGrid recommends exporting your contacts regularly as a backup to avoid issues or lost data.
So this would fulfil that suggestion too.
As for the unsubscribe links, the easiest way is to use the SendGrid unsubscribe form, have SendGrid handle all the unsubscribes, and your exports can keep your database up to date. That also allows you to handle the addition of unsubscribe groups without any more code on your side.
With more work you could create your own unsubscribe form so that your database stays more up to date with the subscription status. Your choice over whether a user should be logged in or not depends on how much friction you want to give the user before they unsubscribe and how much issue you think you might get from users forwarding your emails and having their friends unsubscribe them. That is up to you to decide on though.
Hope this helps a bit!
A lot of Zapier steps have "Choose account" as the second configuration section ("Choose app & event" --> "Choose account" --> "Set up actions" --> "Test action").
Is there any way to select the account dynamically? We want to be able to use the account that corresponds to conditions determined earlier in the zap (i.e. using a value from the output of a step). Right now, we have to manually select the account from the list of connected accounts, and there seems to be no way to change it during the zap.
Which means for each new account that we manage, we have to copy the entire zap just to change the selected account. And then we have an ever growing list of zaps to manage (every change needs to be repeated for every single account/zap).
Background: Our company manages a growing number of accounts -- let's use Twitter accounts as an example. We use Zapier to update these accounts (ex: send out a new tweet) based on some triggers & conditions. Imagine managing hundreds of accounts this way; it's not scalable.
And please don't tell me about Paths. That is not a scalable solution either, and it's limited to only 3 paths (it can be increased to 10, but that's no better).
We're also aware that Zapier has a limit of 2,000 app connections. That's a problem we'll deal with later.
EDIT: We're also considering using an external service to update the accounts (ex: send out the new tweets), so we'd be open to suggestions in that regard. Worst case scenario, we'll build a small custom API to perform the updates on any specified account, and Zapier will call that API instead of performing the updates directly on a specific account.
This is not currently possible - the params of all steps in a zap (selected account, field mappings, input field values, etc) are all locked in at zap creation time.
This is cool feedback though! Definitely worth reaching out to Zapier support about if you haven't.
I am having some trouble using the webhooks Zap with another program called FileStage. I have the Catch Hook and Get enabled. I've been able to do this on one Zap but when I duplicated it (because I need more than 3 paths) it no longer works on the duplicated zaps. I also tested this through the sample data and it worked file, it's just not running with new data.
Any help that you can lend would be appreciated as it helps us streamline our workflow to ensure nothing's missed.
Thanks!
I've been able to do this on one Zap but when I duplicated it (because I need more than 3 paths) it no longer works on the duplicated zaps)
Each duplicated zap gets its own Webhook Url, so you'll need to set up multiple outgoing webhooks in FileStage.
I want to write an update trigger for my Zapier app as Trello has
"Card Updated" - "Triggers when a Card is updated in Trello.". However, I can't find any good examples, any idea how to do that?
Thanks
David here, from the Zapier Platform team.
To understand updates, you must first understand the way Zapier does deduplication. Namely, we keep a list of all the ids we've seen over the lifetime of the zap and only trigger once for each. This makes it easy to trigger on a new card via polling.
The easiest way to do updates is via REST hooks. When there's a change on your end, you POST to us and let us know. The best version of this enumerates which field(s) changes and their old and new values.
While it's technically possible to do this via polling as well, the UX is really tough. Instead of using the id, you'd need to make a new id out of the id and whatever you're interested in tracking updates for. If that was the "assignee" field, you could edit each card in your poll result to have the id id:assignee. That way, when a card was reassigned from Alice to Bob, the dedup system would see a new id (5:alice and 5:bob, respectively). It's hard to extrapolate that out to all fields though, and it's next to impossible to tell what fields changed via a poll. There are some other creative ways to handle it building the id, but the UX to the end user is limited to knowing that a card probably updated (but not knowing in what way).
Hope this helps. Let me know if you've got any other questions!
I'm looking to reproduce the Jira watch functionality in TFS 2013. In Jira, you can click a link to watch an item and thereafter you will be notified when anything on that item changes.
I know on TFS you can:
be emailed if anyone changes a bug you are assigned to
manually email a bug to anyone at any time
Create a custom report and pin it to your home page to notify yourself of things (like this maybe?)
I can imagine creating a new field that will accept multiple users and creating a custom email notification to notify everyone in that list if the work item changes. But that seem like a whole lot of work and I'm not sure were to start if that is the way do do this.
What's the easiest way to get functionality like watching a work item? If it's easy and similar to the Jira functionality that is better for me than exactly the same and hard to do.
Sure, you can setup email alerts based on many different criteria, including what you asked for.
You need to go to the Alerts section, and create a new custom alert, and you can put in the ID of whatever work item you want to "watch". By default it includes the clause AuthorizedAs <> [Me] which will make sure it doesn't email you for changes that you make, but you can remove that clause if you'd like.