Spike: creating custom SF objects

[samschlicht]

Background:

• There was an old Trello issue kicking around that suggested we create an 'Occupations' object for SF, in order to mirror TC occupations - no further details were given.
• In the TC we use a ≈400-item version of the ISCO standard occupation classification - candidates select relevant items from a dropdown when they register and this frames their more-specific 'Experience' entries. It can subsequently be used to filter candidate search.
• It would be useful to have this same list available in SF, where it can be used for candidate contact records and opportunities and thereby reported on and helpfully specified in job opportunities before their TC import.

As well as wanting to understand better this SF feature the specific question is: do occupations need to be an object in SF? What would be the advantages if any over e.g. defining a global picklist value set for a custom field?

[samschlicht]

This article was short and readable and gives a simple breakdown of what SF objects are and how to make them.

To summarise, SF comes with standard objects such as leads, contacts and opportunities but sometimes you have a data object that would be useful to present in the same way (SF objects are essentially a graphic interface for rows in a spreadsheet, with the added bonus that they can relate to other objects, ie. parent job opp <-> child candidate opp). The article suggests customer invoices as a typical use case.

This video digs further into the rationale of when to create custom SF objects.

In short, according to the article the Qs to ask yourself are:

• Is there an existing standard object that represents the data?
• If no (as it is in this instance), is there an unknown quantity of this data that we might need to relate to the record? If no, create custom fields.

[samschlicht]

With regard to this Trello issue, here are some reasons why we might choose not to create a custom SF object:

• There's not a lot of data that we would associate with an occupation - at most, ISCO code and TC ID.
• We don't need to interact with occupations except to relate them to a given opportunity or contact.
• There's no particular reason to need them displayed in a GUI.
• If we want a many-to-many relationship (which I would argue we do), then we also need to create a custom 'junction object', ie the SF equivalent of the candidate_occupation table (here's how)
• For the above reasons, perhaps this is more work than necessary in this instance.

The pros would be as follows:

• We would have the future option to keep the SF and TC occupations table identical via auto API update, using TC as single source of truth. Might save work and safeguard against errors in the long run.
• SF-TC occupations could be connected via their TC ID which means less code and opportunity for human error in API connection. (Connecting via free-text names can invite that.)
• The object can contain the ISCO code and any translations, future-proofing for SF reporting in other languages.

The alternative would be to set up a global picklist value set that reflects the TC's occupation list names exactly. This still offers good reporting and API capabilities but with the disadvantage of needing to maintain carefully the occupations list in both places.

[samschlicht]

My conclusion would be that this is not a typical candidate for the custom-object option, because an occupation doesn't hold much of its own data at all, and so could adequately be captured by a picklist item.

As an ongoing question of where we spend our limited time, this might exemplify an instance where we take the expedient option instead.

That being said, this approach does hold some salient advantages over a custom field. And we haven't tried it before, so perhaps the knowledge gained would make it worthwhile to give it a go as an expansion of this spike?

[samschlicht]

Okay, discussed this with the group.

Useful exercise, but we've opted not to go ahead. John made the point that we generally don't want typed objects on both the TC and SF — ideally the TC will hold the object and SF will accept whatever's passed. (i.e. in most cases a free-text field.)

For the time being, this won't work for countries, since country is set on both platforms — we'll have to keep the lists updated in both places until we are handling job creation in the TC instead of SF.

However, occupations is a great candidate for this approach, so I'm going to give that a go.

[samschlicht]

Noting this rather cool resolution to a concern that I had, which I'll try to explain first:

• a candidate usually has more than one occupation
• we want to pass all of them to SF, but how will that work with SF reporting if we use a free-text field?
• for example, if a candidates 'Occupation(s)' field shows 'Laborer, carpenter, plasterer', SF will count that as 1 entry for the whole phrase — but we want it to parse that phrase and count once for each separate occupation.

Well, there's a lovely solution for that:

• Make a 'multi-select picklist', opt to populate the values yourself and enter the current TC options — but typically that would produce an error when at some point in the future the two lists diverge...
• Fear not! Uncheck the box as pictured: Private Zenhub Image

So, that's how we pass multiple values to SF and maintain its data integrity while keeping the list current in one place.

[samschlicht]

And noting that the same setting is available for single-select picklists 👍

[samschlicht]

Argh, sadly SF's reporting on multi-select picklists is useless! And so it replicates the issue you would have with a regular string (counting the phrase rather than the individual items). However, there is this app, which adds a bit of functionality — so this is probably the best solution short of creating custom objects.

But the custom object debate lives on! Noting of course that the drawback of objects is having type on SF and TC and needing to keep the lists aligned. On balance, multi-select probably still the best option.