I have a lightweight CRM in my Obsidian, where I have notes for people. In these notes, I have frontmatter for their org and role. As these change, I want to “store the change cleverly”
The two immediate ways I can think of doing this:
I could create a new frontmatter filed called ex_company1, ex_company2 etc to store things there
I could just put everything in the company list field and follow some protocol like “the last entry is the current entry” or something
I’d like whatever I do to work with bases, dataview etc. What do people recommend?
I’d make a “past” version of the property you want to change (so for “role”, I’d make a “past_roles” property).
If you’re trying to preserve a set of related properties (like their former company plus their role there), I’m less sure how to handle that in a supported way.
Unless you have a reason to organize people by past roles and organizations, I suggest you keep it simple: keep your current fields for role and organization, and add a # Journal section to the page that logs previous roles and organizations by date. This allows you to see when and where the change occured, and search old roles and organizations, without unnecessarily complicating your system.
More complication can lead to friction, which can lead to abandoning the system.
As a concrete example, here’s something similar to what I do in my vault:
John Smith.md
---
type: "[[Contacts]]"
organization: "[[ACME]]"
title: Chief widget-cranker
phone: 555-555-1212
---
# Notes
- Wife: Sally
- Children: Matt, Mark, John
- Loves football
# Journal
## 2025-09-02
Sent John a commemorative football mug to celebrate his six-month anniversary with ACME.
Give John a call on [[2025-09-16]] to make sure he got the mug and touch base.
## 2025-03-02
John started at ACME. Formerly he was at:
organization: "[[Widget Barn]]"
title: Apprentice widget-cranker
Some thoughts:
I try to keep my properties as simple as possible so that I don’t feel friction when updating them.
When moving old properties to journal entries, I keep the YAML formatting so that they’re easy to put back if I change my mind.
Keeping the link to [[Widget Barn]] means that this page will show up in the org’s backlinks.
Hope this helps – of course, the right way to organize your notes is the way that works for you.
I really like this. I might even use structured links, so [formerly worked at::[[Widget Barn]]]. I guess this will keep things alive in the graph views, but not in the bases… and I guess that’s fine?
how would you structure past_roles when there were many? If the person has worked at 3 places in the past, wouldn’t we have the same problem as if we parsed the list directly from company?
And indeed… the set of related properties sounds like a super big lift… not for now
Well, in this case I probably wouldn’t make them properties at all. When I consider how (or if) to model an attribute as a property, I ask myself “What report or dashboard to I need to see this data on? Is it worth the price of maintaining the property?” With the example of past roles, I can’t think of a report or dashboard where I would want to organize people by where they used to work. It’s rarely pertinent. I can only think of two scenarios where past roles matter:
I’m looking at a contact and want to know where he’s worked in the past.
I’m looking at an organization and I’m interested to know who used to work here.
Neither of these scenarios need a property. In the first case, I can just go to the contact’s page and look at the journal entries, and I can see not only where he used to work, but when he left. In the second case, I can go to the organization’s page and look at the backlinks to see who has ever been associated with the organization.
I’m not saying you shouldn’t make past roles a property. But I am saying that you should count the cost and consider whether it’s worth it. Remember that every property you create is one that you have to maintain – to remember that it’s there; to remember to update it; and to refactor it as your system evolves.
Having said that, if I were to decide that past roles were important to track with a property, I’d probably make it a simple list. It’s easy to manage in a Base and easy to make a report with in Dataview.
company: Example Inc
past_companies:
- Forum Questions Ltd
- Property Structurers LLC
The only problem I saw you mention was determining the current company, which isn’t a problem here because that has its own property.
But I second Craig’s suggestion to consider just logging this in the body of the note unless you have some functional reason to store it in properties.
Thanks… this conversation is really helpful for me to figure things out.
The uses I would have are:
Indeed looking at the person and seeing where they worked
Meeting somebody new, looking up their org to see if I know anyone that works/worked there (local graph w/ named connections and 2-3 jumps will more than adequately cover that)
The additional complication that I didn’t mention is that I have some fancy people in my CRM that hold 5 titles at the same time… if I had 2 properties organisation and past_org, it wouldn’t really tell me what they did… so I think the winning thing will be to hold this property in the body, with proper structure, like:
[formerly Chair of Bladibla at::[[Widget Barn]]]
I won’t be able to shove it into a base… but I think that’s fine.
