Add "created at" and "updated at" in constraints for custom objects

Add "created at" and "updated at" in constraints for custom objects

When creating a custom object in Marketo, 3 fields are automatically created: Marketo GUID, Created At and Updated At.

These fields are not available in the contraints when using a filter to which this new custom object is linked. These could be extremely useful if you are planning on using these to track custom activities in CRM so you can leverage the "before" or "after" in your date ranges based on the Created or Updated at values.

5 Comments
Level 10 - Community Moderator

I sort of like this Idea, yet sort of not... in some systems it's important to have system mod stamps that you cannot be tempted to use in filters, because they can be unexpectedly reset as side effects of other actions.

For example, if you detach and reattach an object (necessary in some workflows) you'll have a new record with a new createdAt. But that field doesn't necessarily have any semantic meaning: the other, user-settable DateTime fields on the object determine its actual business properties.

Hey Sandford,

I completely agree. But there are cases for which it can be extremely useful. In this particular one, I have a High Ed client who creates activities in DCRM when students ask for information via a form on their website (not Marketo form, not linked through API). We want to then target these students based on when they made the request so I'd need to know the created at date. Simply knowing that an activity exists isn't enough. We need a time frame.

In this case, the object will never be detached. It's engrained in workflows and processes to a point where it cannot be decoupled. That being said, if anything were to reset the date, it would be part of said workflows and processes and would still be of high value to the marketing team. Does this make sense?

Level 10 - Community Moderator

Sure, but why can't they add the form fillout timestamp as a DateTime field?  That's the typical way to do it.

Because they store the form fill out timestamp in DCRM on a separate object, not synced with Marketo. That object then triggers a workflow that creates an Activity which would then be synced to Marketo. The goal was to avoid duplicating the field and creating a new one to store the created date (we're not leveraging the native connector).

The developper writing the script can map his created date to the Marketo created at but we can't use that field in the constraints. So in essence, yes, we could duplicate the data but I was never a fan of adding extra fields if one already exists.

Community Manager
Status changed to: Open Ideas