SOLVED

Best practice for data coming into a custom object

Go to solution
Kainelson
Level 2

Best practice for data coming into a custom object

We have a campaign launching that will be pushing data into a custom object. In the past (before I was with the company), we had them come in through one field via JSON string and then parsed out in velocity. We can still do that OR push the info into fields within the custom object. Here are examples of the fields we would create and then push them to: 

 

  • Tier 5 Join date: {marketplace_tier_change_date}
  • Tier 6 Join date: {marketplace_tier_change_date}
  • Temporary stop sell start date:{temporary_suspension_start_date}
  • Next Evaluation date: {next_evaluation_date}
  • Permanent stop sell date: {permanent_suspension_start_date}

I personally think it's easier to push this data into individual fields because it makes it "cleaner" and because it's less work on the velocity side. Just curious if there's a best practice for this? A colleague of mine thinks we should just push to one field and parse it out in velocity but I'm not entirely sure why. Is my approach just lazy?

 

If I did go the route of a one JSON string, can I get some direction or opinions on how should I parse this out in velocity?

1 ACCEPTED SOLUTION

Accepted Solutions
SanfordWhiteman
Level 10 - Community Moderator

Re: Best practice for data coming into a custom object

The reasons to use JSON in textarea fields — and I say this as the person who pioneered the approach! — are:

 

  1. The “shape” of the data is flat but highly dynamic, meaning some object records might have properties A, B, and C and others have props D, E, and F. So you can’t pre-allocate all the possible property names because you don’t know them in advance, and there’s a good chance you‘ll run out of CO fields over time.
  2. The shape of the data is flat and relatively static, but you know from the start there are too many individual fields.
  3. A property is expressly multidimensional, meaning it’s impossible to express as a flat value (e.g. one property holds an array of sub-properties).

It doesn’t sound like you match any of these cases, so I would go with individual fields.

View solution in original post

3 REPLIES 3
SanfordWhiteman
Level 10 - Community Moderator

Re: Best practice for data coming into a custom object

The reasons to use JSON in textarea fields — and I say this as the person who pioneered the approach! — are:

 

  1. The “shape” of the data is flat but highly dynamic, meaning some object records might have properties A, B, and C and others have props D, E, and F. So you can’t pre-allocate all the possible property names because you don’t know them in advance, and there’s a good chance you‘ll run out of CO fields over time.
  2. The shape of the data is flat and relatively static, but you know from the start there are too many individual fields.
  3. A property is expressly multidimensional, meaning it’s impossible to express as a flat value (e.g. one property holds an array of sub-properties).

It doesn’t sound like you match any of these cases, so I would go with individual fields.

Kainelson
Level 2

Re: Best practice for data coming into a custom object

Thank you! That was very helpful. 

 

Question - we are going to be using a JSON text area field for another campaign (I wrote in about the other day). There may be some properties that come in as blank ... does that break anything? For instance if we use this structure:

  "subject line" : "value1",
  "proofpoint" : "value2",
  "oppy ID" : "value3"

and the subject line comes in blank. 

SanfordWhiteman
Level 10 - Community Moderator

Re: Best practice for data coming into a custom object

As long as it comes in as an actual JSON empty string "" that’s completely fine.