Ideas

As part of the GDPR, we need to get consent from people in order to be able to keep their data. If someone registers to download a white paper but does not opt-in, we are supposed to delete any reference to the person. This means deleting it or anonymize it. One very big issue with this is that when we delete the person, it is automatically deleted from all reporting. The work around this is to anonymize the person, since it is accepted that we keep anonymous information in our systems. We can easily replace the first name, last name or email address in the database with "John Doe" or "Anonymous Person". But there are some information that cannot be manipulated from a smart campaign: Cookie IDs attached to the person Inferred and system data such as the IP address Data value changes in the activity logs Fills out form in the activity logs Furthermore, relying on users to run data value changes is error prone. It would be very helpful if a new "anonymize Person" flow step was created. In the field management, we would be able to define which fields should be anonymized, and what would be the anonymous value for each of them (for instance, we would define that the anonymous value for first name would be "Anonymous" and for last name it would be "Person", and NULL for the email address). Then, when running the "Anonymize person" flow step, Marketo would automatically replace all the fields set in the admin with their anonymous value, cleanse the system fields that could be considered as personal Ids and also cleanse all the DVC activities (either deleting them or replacing all values with their anonymous counterpart). -Greg ... View more

It would be great to be able automatically un-sync a program from a SFDC campaign when the program is archived.  ... View more

新規メールデザイナーでは、旧来のサンプルメール送信の方法が「コンテンツをシミュレート」に変わっており、テキスト版のサンプルメール送信ができなくなっているため、対応させて欲しい。 ... View more

The following are the REST API Enhancements we as a user are expecting to see it in near future.   - Asset creator details to be included in the API (Email, Files, Campaigns etc.,) - Flow ID is returned in campaign API, however there is no endpoint to utilize and get the flow details - SmartList Cloning option is there, however there is no SmartList Update option (PUT method for updating the rules/criteria/conditions) via API. Likewise for Files, images can be created via API but there isn't an API option to update (PUT method) it. How come your product team ended up with just providing endpoints for reading and updating the meta data? Why should a development team in a company should create lines of code just to update a file name. I completely don't understand.  - Final member count in a smartlist is not able to be pulled via API, again I'm not sure why this not considered as a meta information. - Worst pagination technique followed for returning records. While trying to pull the Activities (form submission alone) your document clearly states 300 records will be pulled in one single call. Whereas in reality just for 26 records, 10+ calls were used by Marketo API moreResults is set to true but the response will not have any result. What kind of logic is this and the worst part is when we raised a support request they simply said "it's a usual behavior" - I don't understand what kind of behavior is this. - API users are counted under users limit - with that of all these limitations I'm not sure why they are counted. It is atleast considerable to a certain extent for counting the license for users with UI access. Why API users?   I'm a developer and I have noticed such things, when I speak with Marketing team they are giving even more such list. Very Strange tool.   ... View more

I want to add Adobe ID users from SSO-configured domains. The reason for this is that we use Marketo and AEM at multiple locations globally, and although we use a common domain, some locations do not support SSO. Users in SSO-configured domains cannot be added using Adobe ID, so new users cannot use Marketo and AEM. ... View more

There's been previous conversations about how "before" date filters include blank values, and whether or not that is ideal behavior. I think the best solution to this would actually be to add another constraint to date/datetime fields called "include blanks: true/false." That way you could make determinations definitively whether blank dates should be included in each filter. ... View more

Upcoming changes to Chromium are enforcing better policies around using Secure and SameSite flags in cookies. Unfortunately, this conflicts with the way Marketo writes cookies today and could potentially cause major issues for Marketo customers once this is rolled out—Microsoft and Mozilla are also planning to treat cookie flags differently around the same time. Could cookie writing please be updated at a minimum to have the Secure flag set (and preferably explicitly declare SameSite=None when appropriate on third-party values and Lax on first-party)? Otherwise, this could lead to headaches. Getting it prioritized now will ensure the transition is seamless for Marketo customers. ... View more

I was developing a campaign to track records created by Web API users and assign a specific person source accordingly. Although the campaign was set up, it currently qualifies all records created via the API because there’s no way to specify or filter by the individual API user. To improve this, I suggest Marketo to introduce a "User" constraint in the trigger “Person is Created” and the filter "Person was created" to identify which user created the record. This capability would streamline tracking and attribution, making campaign management more precise and efficient. ... View more

Pardot recently announced they are putting several things in place to get rid of bot clicks. One of the simplest ones being IP-based filtering. We have asked Marketo if they could forward the IP address with click data so we could do something about it. Marketo already has this information. Why can't they filter clicks based on IP addresses that many of these security appliances publicise? Rejecting clicks before the email was even delivered, would be helpful too. There are some obvious patterns Marketo to look for - like clicks on every single link or multiple links in a very short timespan. Or clicks that didn't result in a web pageview. We don't have a simple mechanism to link the two, since Marketo doesn't send the clickId to the web pageview. But Marketo has that info. This is becoming a big problem, since we can't do any lead nurturing or other campaigns due to bots clicking. Thanks. Swapna ... View more

If you have a Conversational Flow with a Meeting Booking, and set info capture to "Skip if value is already in database", the meeting confirmation email does skip these fields as well.  That's not a great experience. If the value is skipped, because it already exists in the database, the confirmation email should grab that value from the database. Otherwise the sales person that takes the meeting doesn't get that information.   Here's the confirmation email for a new person that doesn't skip values:   And here's the same confirmation for a person that is already known in Marketo: Sales Person wouldn't know First, Last, Country and Company Name. ... View more

The purpose of this idea is to gather all requirements for the next level of program token management. Here they are : New types of tokens required : URL token types (​) so that managing URLs for CTAs no longer requires a 1 page how-to guide Image / File token types, so that updating a image in a email or LP can be done easily without error (​) Form tokens types to enable changing the form in an LP without editing the LP. See List and smart list tokens () Formula tokens () All tokens providing program information, tags etc... (​) Multi line text tokens (not rich text, but just multi-line) List of values tokens (​ Thx Andrew Sielen​) Select field tokens, so that the standard user cloning programs has the possibility to choose values within a limited list (in conjunction with limited rights, see below). See , thx Robb Barrett Color picker tokens (), which settings could be restricted to a limited set of values. Program level or campaign level UTM tokens that would be automatically appended to emails links PURL tokens (see ) Asset (email, Landing page) tokens, that would provide the asset name, the asset ID, the asset template (see ​) Tokens that could store value lists to be used in forms 2.0 select field values (see ) User/sender tokens should also be available for MSI emails: (Thx Josh Hampleman ),   (Thx Aqeel Akbar) and Change the Date Token to a DateTime.  When used for a webinar it'd be nice to be able to put in the time of the webinar, not just the date, so that we could use the token on reg page. Have a Time Token that automatically parsed it into local timezones. If I set the token for 12:00 CST it'd be nice if it showed up as 1:00 EST on the landing page, based on their locale. Tokens to set CRM users that could be used in lead assignment flow steps. See Furthermore, we should be able to access campaign/program member values as tokens, including SFDC custom fields on the campaign member object (see ​) We should also be able to access all SFDC campaign fields as tokens in Marketo programs. See ​, ​, ​, ​ and this one ​ and this one: ​. Of course, all these would be used in flow steps (such as change data values, interesting moments, SFDC task creation, etc...) and in assets Token management also needs some significant improvement : We should be able to know easily where a token is used (see ​, thx 54930​​ and ​, thx Jordan Lund​ Token name change should be propagated to where they are used (see ​, thx Boris Kiperas​​) We should be able to nest tokens (​, thx 77896c23b3a73646ac738677aabf9c4454ddc324​​ and ​, thx 3f4b511b1ff3aa191ec9a659bd8f25e857df9b7e​) Token definition should be separated from token value entry. We should be able to control who can create / delete tokens or edit token names or settings (see ) and it should also be possible to control who has the right to edit token values. Cloning tokens should be easy (see ​, thx Cecile Maindron​) and moving them should be done without having to recreate them (see ​) It should be possible to override token values down to each asset (see ​, thx @Alan Brown) We also would need to have the token inheritance to be brought to full power with root folder tokens (see ) It would be welcome if the tokens could be ordered in programs or folders to make them easier to manage. See ​​ Ability to create validation rules on token, to ensure correct entries (Thx Robb Barrett​) Token input should be submitted to some validation. See It should be possible to append some help text to tokens. See Finally, token usage should also be strengthened : "My tokens" could be used as default values for field tokens (see ) My Tokens to be used to be default values for forms 2.0 fields, including hidden ones (Thx 14675​) see here ​ More token drop lists everywhere tokens can be used. Using local tokens in forms 2.0    (Thx Dan Stevens​). Great one It should be possible to use tokens in filter and trigger parameters and constraints. See (Thx Jeff Shearer​) and more globally in all smart lists in smart campaigns. See (Thx Dan Stevens​) UTM tokens should automatically be appended to all email links. see ​ It should be possible to update {{my.token}} values from within a smart campaign. See ​ Use of tokens to populate form field list of values () Program, lead and company tokens should render in MSI. See (Thx Alex Stanton) All these improvements, combined, would lead Program + tokens technology to a unmatched productivity tools for marketers in small to very large teams. -Greg ... View more

New possible duplicate records could be found by adding new fields or combination of fields in the "Duplicate Fields" filter. Besides the existing ones, we believe the following ones would help detect duplicates: 1- Mobile Phone Number 2- LinkedIn Profile URL 3- Combination of First Name, Last Name and Company Name And we understand the level of complexity of doing so should be relatively low. ... View more

We’ve seen a sharp spike in unsubscribe rates in recent months. Unsubscribe logs show users being marked as unsubscribed across multiple emails (see image), with entries spaced just 5 minutes apart—this does not reflect actual user behavior.   This issue began in June 2025, coinciding with the rollout of one-click unsubscribe by major email providers. It now inflates unsubscribe metrics, distorts performance data, and raises serious concerns about potential domain reputation impact.   Other Marketo customers are reporting the same problem. This is more than noise in analytics—it’s a systemic issue that demands urgent investigation and resolution.   ... View more

Currently, Marketo forms are limited to single-page layouts. If we want to create a multi-step form (where users can complete one section, then click “Next” to proceed to another), it requires custom code or third-party tools. A native multi-step form feature would be really useful because: It improves user experience by reducing form fatigue. Instead of seeing a long list of fields at once, users can progress step by step. It often increases completion rates, since breaking questions into smaller chunks feels easier to complete. It makes it possible to collect more data without overwhelming prospects. It keeps the form design consistent and aligned with Marketo’s existing functionality, instead of relying on workarounds. I’d love to hear if others have faced the same challenge and whether this would be a valuable addition for you as well. ... View more

Some time ago, Adobe recommended using the “share with a friend” option, but this feature is no longer available: https://nation.marketo.com/t5/product-blogs/deprecation-of-forward-to-a-friend/ba-p/358045#:~:text=As%20of%20September%2029%2C%202025%2C%20the%20Forward%20to,been%20or%20will%20be%20sent%20using%20the%20token.   We need a way to share emails with internal personnel for review before sending them out. Since we are working with the new email designer, we must avoid adding employees as additional contacts in Marketo, as these would count against our license. ... View more

Due to a Salesforce input error, we need to find emails from outside the United States ending with a local email domain in our database.   Can we add a filter into the Email Address for "ends with" ?  such as .co.uk .fr . de . see .it etc to identify Country. As often, only two letters using the "contains" filter brings in too many additional addresses where the letters are part of a name or company.   This will also help with reporting, personalisation and target audiences.   Thanks, Zoe    ... View more

As customers utilize newer features within GTW, the use case for this feature will grow and it would ideal for the integration with Marketo to support this. ... View more

One of the question I get the most often when training Marketo customers is how can create fields that are attached to leads only in the context of a program. An example of this is sending invites for an event and ask for preferences in a field on the form, such as which track they will want to follow, what timeframe they would want to come, etc... For a few quarters now, SFDC has offered the possibility to add custom campaign member fields. This idea would be to enable programs in Marketo to support similar custom member fields, but also some standard campaign member fields that are not currently mapped, such as the member status date. Creation of the program member fields The program member fields would be created automatically from the synchronization of salesforce campaign member standard and custom fields, as for any other field we sync. As with other SFDC fields, the "self healing" schema capability would be required. It should also be possible to create such fields directly in the Marketo admin section, either when one does not use SFDC as a CRM or when Marketo admins would want to benefit from the capability without going through the burden of modifying SFDC schema. It is important to note than, as with lead fields, both Marketo only and CRM sync'ed fields should co-exist Some program member fields would also exist by default in Marketo to host information such as Program Member Status and date, success and acquire by information. These fields would be synchronized by corresponding ones in SFDC if the program is syncrhonized. This means that Sync'ed member fields and unsync'ed member fields would be able to co-exist in the instance, as for lead fields. Obviously the program member fields meta model would be the same for all the programs in the instance, and all the workspaces Some campaign member fields in SFDC would also be created as part of the MLM package, such as "acquired by" checkbox field and "acquisition date". The Acquired by would also be used in a rollup field in the campaign. [EDIT] as the MLM package does not exist any more, it should be possible to create these fields in SFDC, with a specific syntax, and they would automatically be recognized and mapped by Marketo (as it's now done for the lead score for instance). Population of the fields The program member fields values could be used in forms and filled out from there. The values entered in the form would be stored in the program containing the landing page hosting the form, provided that the LP is hosted in a program. The program member fields would be eligible to the hidden field feature in form so that they could be populated from referrer, URL or cookie values. In case a form is embedded in a non Marketo LP, if the form belongs to a program, the values would also be stored in the program. In case of neither the form nor the LP belong to a program, a hidden standard field or a form parameter could be provided (or added to the form code for an embedded form) that could host the name (or any other ID) of the program supposed to contain the data It should be possible to update the value of the program member fields with simple "Change Data Value" flow steps, in smart campaigns, only if these smart campaigns are located in the context of the program. It should be possible to populate the program member fields through import of members in a program or import into a list located in the program. In case of import into a list not located in a program (a Lead Database list), the import would prompt the name of the program to import these values in ("None" would be a possible answer, in which case the imported program member field values would be lost ). These fields values would also sync with SFDC, so the fields value could also be populated from SFDC. Sometimes, these fields might be formulas in SFDC, in which case they would be read-only in Marketo. Materialization and usage of the program member fields The field values would obviously be available only within a program context, somewhat similarly to program "my." tokens, but with the difference that each lead being a member of the program could have different values. These fields would be available as "program." tokens (to differentiate them from the "my." tokens) and usable in all assets within the program. These program tokens would even be available for webhook payloads. These fields would sync with SFDC campaign member fields, in a 2-way sync, if the fields are mapped with SFDC fields. These fields would also be available to filter leads through constraints for the "member of program" filter and the "Program Status is changed" trigger The program member fields would also be eligible to the "data value changes" trigger and the "data value changed" filter. Alternatively, a separate set of filter & trigger could be created. The program into which the filter applies would be set through a constraint (which value could be set to "is any") The Marketo event mobile app should also be able to leverage these fields to display them or to allow update. The program member fields should also be accessible in read and write modes through the API. A new "campaign member" API will obviously be needed for this. When added to a view in a smart list or a list, these program member fields would display a value only if the smart list belongs to a program Reporting: These program level fields would be used as additional filters in the program performance reports. It should also be possible to add the program member custom fields to generate custom columns in the program performance report. In this case, each possible value of the chosen field would create a column and the rows would provide counts. They could also appear as filter, breakdown or grouping field in the program analyzer. It should be possible to add these fields to the revenue Explorer, as additional dimensions. Especially key to all program oriented report types Example of use cases Storing program membership source tracking, in a much simpler way, without to have to create a complex structure of multiple programs by source. That would make the creation of an offer-channel attribution model so much simpler! Storing visitor food preferences for an event Soring registration date/time to and event or subscription date time on an opt-in and being able to report on it easily Capturing visit hours choices on a tradeshow booth Store a membership date that would be different from the date/time the program member record has been technically created Last but not least, create a very significant differentiation against Marketo competition, with regards to the way SFDC campaigns are integrated and supported (and hopefully one day for MS Dynamics as well). Store the date at which a form fill out was performed for each lead Greg ... View more