Question on Best Practices with Referential Properties (Layered Properties?)

[AZistler]

Hello all! Thank you in advance for any assistance.

We're currently deciding how it's best to organize properties for reporting, workflows, etc. We've run into a bit of a tricky question, and we're hoping we could receive some guidance on what is the best practice in this situation, and why.

Currently, we do not have a single property that denotes a current client. We're planning on using (“Lifecycle Stage = Customer” AND “Release Date = false”) to denote current clients.

Our sticking point is: should we then create a final "Current Client" property that updates via workflow off of the above - OR - when creating a workflow/report/etc. simply use the function above?

Creating a separate property seems simpler to use, but much more complicated should our process change / new team members need to use it.

However, using the function itself seems more complicated to use initially, but less tricky should process or users change.

Any advice on if it's a good/bad idea to layer properties, in general, would also be greatly appreciated! Thanks again. 🙂 

[karstenkoehler]

Hi @AZistler,

Could you provide some more context as to why you are using multiple properties for the customer status of a contact? In which ways is the Lifecycle stage value "Customer" insufficient? Which purpose does the Release date property have?

Knowing all the requirements and your process will help with finding a solution.

Best regards!

[AZistler]

Hi Karsten!

Thank you for your reply. I worry explaining the specific process would confuse the qestion more.... We know there's likely a better overall process, but our hands are tied between multiple departments having their own say with certain properties, etc. Anyway, here goes:

We're kind of a mix of b2c and b2b. We measure clients at the company level, but end-users are measured at the contact level. We were originally using Lifecycle stage = "Customer" but it ended up automatically bringing in contacts from Deals that were not end-users. 

So, the solution was to assign all (Lifecycle stage = Customers) that are end users a "Release Date." If it's false, they're a current end user / customer. If it's true, they've been released, and are a past customer. (If released in the company object, they're a past client.) yes it's confusing.

We realize that might not be the best solution. However, my question is a bit aside all of that and can apply to really any situation. Basically with this set up (or any similar property combination to denote something) is it best practice create an additional, single property that is automatically updated from both?

So, in this case (Lifecycle stage=customer AND Release date=false) = current end user.

So then, my question is this: is it then best practice to then create an additional property called "Current End User" and have a workflow assign that property to specific contacts (For use in workflows, lists, etc.), from the above combination? OR is it better to just use the combination above every time we need to denote an end user for active lists/workflows etc.?

I apologize, I know this is a bit of a confusing question made only more confusing by our current wonky use of the system. 

[karstenkoehler · Accepted solution]

Hi @AZistler,

Always using both properties introduces a risk for error. I would, in this case, create an additional property that is clearly named and understood by everyone in the company. Unless you're hitting a limit for custom properties, I think this would be useful.

It comes down to personal preferences, but in reporting alone this would facilitate a few things.

Best regards!