Recommended Approach for Dynamic Date Ranges in Marketo’s Velocity Scripting

[dtavangar]

Hi Everyone,

I’m exploring the best ways to handle dynamic date ranges in Marketo’s Velocity scripting for a use case where opportunities need to be filtered based on whether their close date falls within a specific date range (e.g., today and 1 week prior). I’ve been testing some approaches and would love your insights on the best practices for this.

I opted for text tokens over date tokens because they are easier to compare using .compareTo() in Velocity, avoid complications with time components and formatting, and provide flexibility for preformatted external values. However, I’m open to switching if date tokens can dynamically resolve and better meet the use case.

What I’ve Tried

• Preformatted Text Tokens: Using text tokens (e.g., currentDate and dateRangeStart) formatted as yyyy-MM-dd to pass date values into the script.
• Hardcoded Testing: Replacing tokens with static dates to test the logic. This works but isn’t dynamic enough for long-term scalability.
• DateTool Attempts: Experimenting with DateTool for dynamic calculations but encountered some formatting and functionality challenges in Marketo’s Velocity environment.

Questions

1. Best Practices: What’s the recommended approach to handle dynamic date ranges in Marketo’s Velocity scripting?
   • Are there alternatives to DateTool?
   • Should I use a different type of token (e.g., a date token instead of text)?
2. Dynamic Date Handling: How do you handle date comparisons and calculations (e.g., subtracting days) efficiently in Marketo’s Velocity scripting?
3. Token Resolution: Are there any considerations or caveats when using text or date tokens with Velocity scripts?

The use case involves filtering opportunities to show only those with a close date between the current date and a specific range (e.g., 1 week prior). Current tokens are preformatted as yyyy-MM-dd.

I’d love to hear your approaches and recommendations! Thanks in advance for your insights.

[SanfordWhiteman]

I assume you mean Date fields, not Date tokens (as in {{my.tokens}}).

There's no reason to use anything other than Date fields and DateTool ($date). Formatting of Date fields in Velocity is 100% predictable, and they will be validated on the front end, unlike a String field which can - and inevitably will - contain invalid ISO dates.

If you search my past blog posts I've written extensively about date math and comparison in Velocity.

[dtavangar]

Hi Sanford,

Thank you for your response and for the clarification on the use of Date fields and DateTool.

So just to be clear I’m using Marketo Date tokens ({{my.currentDate}} and {{my.dateRangeStart}}), formatted as yyyy-MM-dd. While the tokens themselves are valid, $date.parse() in Velocity consistently fails to parse them as proper Date objects, which prevents the script from executing the filtering logic correctly.

I’ve reviewed your blogs and posts about date math and comparison, but I suspect there may be a limitation or caveat when working with Marketo Date tokens in Velocity. 

so my questions are 

1. Is it possible to dynamically resolve Date tokens in Velocity and parse them for date comparisons?
2. Would you recommend an alternative approach to handle dynamic date ranges effectively in Marketo Velocity scripting?

Your insights are greatly appreciated, and thank you for all the guidance you’ve shared with the community!

[SanfordWhiteman · Accepted solution]

By "dynamically resolve" you mean "use"?

There's nothing specific to {{my.tokens}} of the Date type, no. But of course there's a problem with all non-Velocity {{my.tokens}}, which suggests you didn't check to see if the variable exists at all in Velocity!

You probably want to read this post: https://nation.marketo.com/t5/product-discussions/referencing-program-token-in-email-scripting-token...

[dtavangar]

Hi Sanford,

Thank you for the clarification and the link to your post - it was exactly what I needed. 

Your explanation and article have cleared up the issue, and I’ll adjust the script to properly preprocess the tokens before use. I really appreciate your time and expertise—thanks again for pointing me in the right direction!