Best practice for data coming into a custom object | Community
Skip to main content
K
Kainelson
New Participant
April 18, 2024
Solved

Best practice for data coming into a custom object

  • April 18, 2024
  • 1 reply
  • 1575 views

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?

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

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.

1 reply

SanfordWhiteman
SanfordWhitemanAccepted solution
New Participant
April 18, 2024

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.

K
KainelsonAuthor
New Participant
April 18, 2024

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
SanfordWhiteman
New Participant
April 18, 2024

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

Terms & ConditionsAccessibility statement

Loading footer...