Yeah definitely, I makes it easy when you are the lead admin for both platforms 🙂   FYI: We tested and it all works now (yay!) ... View more

I think both our methods are similar mate. They both abstract the trigger logic into a single field, and use that field to spawn the re-roll to occur once 🙂   I'm a big SF dude, so using the SF process step to check for any changes and flag a boolean seems like the easiest and cleanest way for me.   Thanks and I'll report back if this works. I've also sent @Edward_Unthank_ a tweet to see if he came across this issue in his logic before or not. ... View more

I had an idea. I could puish this back to Salesforce to handle the triggers and abstract it into a single boolean instead. So basically, have salesforce calculate if one or more of those fields are changed, update a checkbox to true to tell marketo to rerun the demographic score recalculation. Then update the trigger in Marketo to be a change to that boolean and = true. Then at the end of the recalc, reset the check to false. ... View more

So this would help you all understand the issue better: https://youtu.be/Id1xfYvIiJE?t=1907   We modelled this off Edward's architecture. When you see the "Gating ReRoll" Campaign, you will see he also has multiple triggers, but I can't figure out how this would not also result in a CRM sync firing off multiple parallel campaigns when mutliple data values are changed from a single sync.   The consequence is that each campaign starts at a slightly different timestamp, so the first campaign might reach a score flow step and add +20, but then the second campaign starts, and sets the score back to zero, so these parallel campaigns are affecting the score field at the same time, but out of order. ... View more

Exactly! ... View more

Hi Amit,   Here is the flow and also the daisy chain. Essentially, it resets person score back to behaviour score, then kicks off a chain of request campaigns.   The issue is that if this chain is started 3 times from 3 data value changes, yes, it tends to double the end result, or not quite double as there is three campaigns running, all making demographic score changes in parallel.   ... View more

Hi Chris, Yeah, we do sync our lifecycle program into SFDC and I agree with having a single MQL lifecycle status. I went ahead and solved this with the counter and timestamps. Here are screenshots from the dashboard and report I created to support us seeing MQL's over time, grouped by lead source. What's nice is that we can then see where they have move to in the lifecycle. With the counter visible, this also highlights any re-mql's. My lead source data is still a WIP, but this is a good step forwards. ... View more

Hi Chris, In my previous statement though I am suggesting/questioning that even Marketo themselves is taking a position that they would be OK to find a person (let's say CMO of X company) who has not "requested information about one of your products" and could qualify based on their role and the company begin demographically fit for their offering, that legitimate interest is met. They could then market to that person (sales outreach, nurture) regardless of them providing explicit consent. That's how I am reading their policy. Your thoughts? ... View more

So, I may be coming around on this legitimate interest thing. This is from Marketo's policy... Privacy Notice » Marketo Documents  Our legal basis for collecting and using the Personal Data described above will depend on the Personal Data concerned and the specific context in which we collect it.  We will collect and use your Personal Data where the processing is in our legitimate business interests, such as for direct marketing and sales of Marketo’s Marketing Automation Platform and Applications to prospective Business-to-Business (B2B) customers.   Our legal basis for processing Personal Data in certain circumstances will also be based on your consent to do so or where we need the Personal Data to perform a contract with you or in order to enter into a contract with you. In some cases, we may also have a legal obligation to collect Personal Data from you. So basically, the way I am reading the law, is that there are multiple categories that allow for personal data to be collected. Consent is one, legitimate interest is another. Under LI, it is worded to say LI for US or LI for them. Under "How do they collect information" they also state "Information From Other Sources:  In order to enhance our ability to provide relevant marketing, offers, and services to you, we obtain information about you from other sources, such as public databases, joint marketing partners, social media platforms, as well as from other third parties."  So that could mean for example, an email address from a prospect's public website in the public domain. Here is a statement from Salesloft "Let’s start by taking a look at how GDPR will affect prospecting. The regulation doesn’t directly call out cold calling and cold email, but it does require you to have a legal basis to process data. Two common legal bases for processing are consent of the data subject, which is your prospect, and legitimate interest of the controller, which is you." The law states that so long as the person could likely expect you to process their data, then it's OK. So most people are in fact reading this as "fit for business". I'm reading/thinking that the regulatory body is more about getting people to think better, spam less, make marketing more personalised and more targeted. It's not trying to stop people marketing all together without consent. The "rights of the individual" under legitimate interests are ambiguous and I believe designed to protect people such as children etc.   "legitimate interest balanced against the fundamental rights of data subjects" Now, this data provider of mine is still bad because they are not stating that they are reselling people's data in their Privacy policy, where as Marketo's states the following:  How Will Marketo Share Personal Data It Receives?  Third-Party Business Partners: Marketo partners with a variety of businesses and works closely with them to market or sell products or services. In certain situations, these businesses operate within the Sites. We may disclose Personal Data to our partners for the purposes described above. Some of our third-party business partners co-sponsor events and other offerings with Marketo. We may share Personal Data with these co-sponsors when you sign up for events or offerings to allow our partners to send you marketing communications and information that may be of interest to you, as permitted under applicable law. Maybe I am wrong after all.  I mean Sanford's comment above was in response to them selling the data to me and not stating so in their policy. But Forget that provider breaking the law for a second. If we procure a record of a person and stand by that our legitimate interest is that we believe they are a decision maker and thus should reasonably expect us to target them as a prospective B2B customer, providing the means to opt out and making our privacy policy clear in those communications, and that this does not infringe on their fundamental rights, then I think we're OK. There are some very large companies taking this stance and select few that are going "consent only" for EU, some going consent only for all. Maybe, until there is precedent of punishment for a targeted b2b email, then we should not limit ourselves? ... View more

OK I have two more questions: I am a sales person and one of my target accounts is a company (in my case school) in the EU that I want to reach out to. I find a contact that is known to be a decision maker for purchasing my product. Can I create a record in my CRM and reach out to this person via email?  Can this email for a known decision maker then be emailed by my marketing team on the basis of legitimate interest? Don't be shy here people, tell me your thoughts? ... View more

Yeah, too many people wanting to believe that they can use "target persona who's a fit for what we sell" as grounds for legitimate interest. Ideally, GPDR people would throw a single large company under the bus for this and set the precedent.  ... View more

Thanks. Coming from you this really helps me bed down my belief. So basically their business is this, in a nutshell: UK based data provider in niche vertical market space They collect (via any means necessary) data on people around the world, including EU  They confirmed that they do not seek explicit opt it at any point Their position is that so long as they email them within 1 month of adding them to their database and that email includes an opt-out link, that they are compliant. Further, they then on-sell that data to 3rd parties and state along the whole road that so long as the people are a fit for business, that implies their consent.  What a joke. They are clearly convincing themselves that despite GDPR, their business model is legitimate, and their lawyers (they told me two separate counsels) know sweet f*$& all about the law they are consulting on (why am I not surprised there). OK, well that confirms for me that any of their records from EU countries, I don't have any legal right to import into our system, let alone market to. Crazy. ... View more

Given that we are not currently going to nurture those people any differently, nor do we need any changes to responses from sales team based on it, We'll just do the counter from a data keeping perspective and leave the lifecycle simple. ... View more

Exactly. Thanks for confirming. ... View more

Hi Justin, Thanks for taking the time to reply. In our case, I don't believe we meet the needs for a "truly cyclical and multi-dimensional lifecycle" but maybe aspects of it.  Our typical sales scenario would be a multi stakeholder long lifecycle. Sales could take up to 5 years and might involve different people at different times, BUT, the school as an account, will only buy our product once (then recurring subscription). So what can happen is that they start investigating us and competitors with the intention of buying, get demos/presentations etc, then they may either loose momentum and not select anything, then wait for another 12/24 months (prospect re-engage/recycle) and then their active sales process begins again as an account. Or the other scenario is we lose the first deal, then 2-4 years later, then look for a better solution and come back into our sales funnel (once again the transition from prospect re-engage to MQL as an account). So We need a way to Re-QL people and we're currently refactoring our lifecycle to create the whole "Contact Status" and  allow people who have already moved from lead to contact to once again get MQL'd. So at the point that they do that, do you think there is value having a RQL bucket in lifecycle, or just an MQL counter? E.g. This first model would include the counter instead of a lifecycle stage: This second model would include the stage instead of the counter : I'm not sure there is actually much difference, other than maybe the reporting differences. ... View more

Thanks Sanford. We'll try a proxy field then, I just figured from the documentation I could find, that if I created a person with a false value, that it would override the durable table value on creation, it does not appear to be so. Appreciate the response. Cheers, Sean ... View more

Yeah this one really shocked me. When SSL is now free, how can they charge us for it. We provide all our customers SSL for free, in a fully automated way. ... View more

Great conversation here and thank you for your detailed response Justin. Loving it. However, I find it more flexible to update relevant lead/contact fields in Marketo with the various data points you want included in the task, then update a date stamp field that triggers a process or apex in SFDC to create the task, pulling from those fields. This way you can populate custom fields on the task that Marketo can't access or use more complex logic if needed.    This process assumes that you are routing leads to a named owner by the time they reach MQL. If you are triaging out of a queue, it won't work as you can't assign tasks to queues.  Understood. We need to deprecate the Queue anyway but were considering just assigning them to our API user who owns all records not owned by people. We don't have a requirement at this stage for complex lead routing by territory etc, although we'll probably grow into that need. Funny thing is, we do have a single person who triages, so I'll have to think if it improves things to just assign to them, given that's the reality, why not. Some benefits of using tasks generally are:  Allows sales to work on both leads and contacts from one consistent view, without switching objects.  Allows you to notify sales about multiple inquiries from the same person even if they are already in a later lifecycle stage. Provides a more flexible way to track lifecycle and SLAs, particularly as the funnel grows more complex and less linear - i.e., multiple products, cross-sell and up-sell, etc.  I like the position on keeping the sales working process the same across both objects and agree that tasks provide the ability to abstract that. Our current plan was to move the MQL Queue to a report, then duplicate it for Contacts. Same for Working (SAL) People, just have two lists, then bring it all together for reps on a single SF Dashboard. RE: Multiple inquiries: We are still able to handle multiple fast track inquiries as we've abstracted our MQL Alert from our fast track form Alerts, which means we actually fire two alerts if the person makes an inbound fast track inquiry and MQLs. And we're cool with that as it also means we get the benefit of instant alerts if a repeat inquiry is submitted. I also agree that tasks provide a excellent object to build that SLAs and have a range of different tasks types etc. Q: Do you use SF record types on tasks? If so, can you share the scenarios? The more challenging piece is usually designing how you want the process to work and getting alignment with all your stakeholders.   In particular, make sure you define the reporting you want in detail up front, so you can ensure that your process will supply the data for those reports. We're pretty lucky and dynamic at this time so alignment with sales won't be hard, in fact, this is more of an improvement project than a start from scratch. We audited our lifecycle programs across Marketo/SF over the last two days and estimate about 3 weeks work for two of us to complete the refactor. That's before we then add these Flow based wizards etc. We agree that defining reporting requirements from the start is key to mapping the processes and functionality needed to deliver the data for them. I think the main thing for us would be: Reps to see their pending follow ups (SLA), discovery/qualification tasks (for MQLs) with is also an SLA, their current working leads (with amount of time in that working state, i.e SLA) Sales manager, same but with oversight over the team I really appreciate you sharing, particularly that wireframe, it's good food for thought. I can see myself investing a lot of time on this next iteration.  We had never thought about Flows to drive these processes, so you've unlocked a new Pandora's box for me!  ... View more

Hi Justin, When you talk about using tasks to inform sales, can you share a little more about how this process works? We currently promote a lead to MQL status and assign it into a Lead Queue call "MQL Queue" which then get manually triaged by our SDRs. How do you do it?  Also, this process we have is not going to survive because we're about to refactor our lifecycle to establish a shared Lead Status across Leads and Contacts so obviously Contacts won't be able to be assigned to the Queue. I get that we could simply lock down picklist values, but I am looking at going that next step and really making it cleaner. As you sometimes need to have values available for edge cases (or user mistakes), but don't want people to use those values. A wizard based approach seems way cleaner in the long run. Any chance you can send me some screenshots of the flows? sean.richards@schoolbox.com.au if possible. I totally understand that Flows are limited compared to Apex. We have coding capabilities but haven't dived into Apex land yet, not to say we can't/won't.  What were you trying to achieve with the "background lead conversion action"? Thanks as always for sharing this insight! Sean ... View more

Thanks so much for coming back to me on this Grégoire. So in the case of the "qualify lead" wizard, what fires off this Flow to execute? Or is it more that from an MQL lead queue (or contact list) the reps can open the lead/contact then press a button to launch that wizard? Any chance you have any screenshots you could share to get me started reverse engineering it and customising for our scenarios? If not, no stress, I think this will still get me going in the right direction. I really like both examples you provide. I do have a plugin customised at the moment that forces Contact Roles. It's working well. Every week I get a report emailed to me with Oppty's without Contact Roles and it's always returning zero  Lucky I have a small sales team that I can keep trained. Much appreciated! Cheers, Sean ... View more