Use cases for custom marketo objects? | Community
Skip to main content
Darrell_Alfons2
Darrell_Alfons2
New Participant
April 24, 2017
Solved

Use cases for custom marketo objects?

  • April 24, 2017
  • 2 replies
  • 5244 views

I've been studying up on marketo objects and am wondering how I can leverage this.

Any great use cases out there?

Or is it really just custom per business.

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by SanfordWhiteman

    In theory, any N:1 Thing:Person relationship, where Thing is not a high-density time series but rather a relatively static characteristic or dimension, might be implemented as a Marketo CO.

    In reality, the opacity of the REST API and other limitations have made COs more of a last resort in our experience. We do use them: examples are multiple Area of Interest records for a lead; multiple Season Tickets held; multiple Stock Positions, Products Registered, Courses Requested, and UTM Events. But almost always we wish we had used a different implementation.  For example, for storing multiple product interests on a lead, a single JSON-formatted text field is far more efficient and easier to update than creating a new CO each time.

    The limited number of COs (10) that you get to access from Velocity has proven a major obstacle.  If I want to customize someone's emails based on currently held warranties, better to store records in a textarea field, where if each record is just a couple of string fields there could be hundreds of entries instead of just 10.  And for any data you want to display on an LP ("Welcome back, here are your holdings") you can't use COs at all.

    YMMV, but a thorough review of what you're trying to do is the only way to decide if COs are the only choice.

    2 replies

    Rachit_Puri2
    Rachit_Puri2
    New Participant
    April 25, 2017

    o

    Here is a use case from B2C side.

    We helped a publishing house with the implementation of custom objects in Marketo. The leads could be interested in multiple books. Also, a single lead could have purchased some books and would be interested in other books. We wanted to run drip campaigns, where the email would include a table with the list of the books which the lead is interested in. We started storing the data in the Marketo Custom Object via the API. The fields from the custom object were inserted in the email using a scripting token.

    Custom objects are good to use where you can not use custom Salesforce objects in Marketo to fetch data or use them in emails. The use cases would vary for different business processes.

    SanfordWhiteman
    SanfordWhiteman
    New Participant
    April 25, 2017

    We started storing the data in the Marketo Custom Object via the API. The fields from the custom object were inserted in the email using a scripting token.

    Right, this is an okay fit for COs but a far better fit for JSON storage, since you have all of the benefits and none of the drawbacks (API limits, script access limit of max 10 COs, no LP use).

      Grégoire_Miche2
      Grégoire_Miche2
      New Participant
      April 25, 2017

      In fact, the only limit with JSON storage is the size of the long text field in Marketo, which is 32k, AFAIK.

      -Greg

      SanfordWhiteman
      SanfordWhitemanAccepted solution
      New Participant
      April 24, 2017

      In theory, any N:1 Thing:Person relationship, where Thing is not a high-density time series but rather a relatively static characteristic or dimension, might be implemented as a Marketo CO.

      In reality, the opacity of the REST API and other limitations have made COs more of a last resort in our experience. We do use them: examples are multiple Area of Interest records for a lead; multiple Season Tickets held; multiple Stock Positions, Products Registered, Courses Requested, and UTM Events. But almost always we wish we had used a different implementation.  For example, for storing multiple product interests on a lead, a single JSON-formatted text field is far more efficient and easier to update than creating a new CO each time.

      The limited number of COs (10) that you get to access from Velocity has proven a major obstacle.  If I want to customize someone's emails based on currently held warranties, better to store records in a textarea field, where if each record is just a couple of string fields there could be hundreds of entries instead of just 10.  And for any data you want to display on an LP ("Welcome back, here are your holdings") you can't use COs at all.

      YMMV, but a thorough review of what you're trying to do is the only way to decide if COs are the only choice.

        Grégoire_Miche2
        Grégoire_Miche2
        New Participant
        April 24, 2017

        +1 on Sanford's.

        I would add a couple of other major obstacles:

        • Impossibility to display them in the UI if they are sync'ed with the CRM
        • Impossibility to create CO instance from a form or a flow

        -Greg

          Terms & ConditionsAccessibility statement

          Loading footer...