Tinderbox Forum

Using TBX as a CRM/CMS?

I’ve been using TB for a while now. Mostly for notes and some planning. Over the COVID-19 period I needed a fast agile system to keep connected and look after people in a church (I’m a church minister). TB performed really well and helped keep on top of who was isloated, in hospital, who had been called, who needed a call, etc.

I had planned to build a complete CRM in PanX, but have not been relishing the learning curve. TB having managed so well, has made me wonder if it would work as a type of CRM in my context?

What are the requirements?

  1. Contact info - easily done with attributes
  2. Keep log of contact with individuals - also possible
  3. View data via different attributes - attribute browser.
  4. Manage tasks/projects - I’ve done this in the past so it is possible.

So far so good. There are a few more complex (for me!) needs:

  1. Relating individuals to families and households. It would be useful to know who is married to whom, who is related to whom and who is living in the same household. - Not sure how to accomplish this.
  2. View attributes in different ways. We celebrate special events such as birthdays and anniversaries. Can TB take the data such as DOB and display it in terms of age in a list by month?

There are many other aspects that I would want to add over time. Things such as who is volunteering where, booking and room hire, policy management, charity commission requirements, depts and who is involved in different depts, building maintenance, who’s in what small group, and the list continues!

Is this something TB would do well or is it better handled in a database like PanX? Would appreciate any thoughts on this!

I think Tinderbox can do this fine, and Panorama can do it too!

If you expect more than 10,000 contacts, Panorama is helpful. If you expect your information to change over time as you adapt and learn, Tinderbox might be more flexible.

On relating individuals to families and households: I can see several approaches. One would use links, with the link type expressing the relationship. Another would use attributes like $Spouse, $Children, or $Sibling. I’m not sure which is better; I’d choose one and try it! You’ll have similar issues in Panorama, of course.

It’s fairly easy to convert date of birth to age; so that shouldn’t be a problem.

Contacts will be below 500. I keep forgetting about links. I think I’ve used TB so much with KA that I tend not to think about links. Links would be really good for creating those connections.

I like the fact that you can just throw a bunch of stuff in TB and shape it as it grows, rather than needing to get the structure right at the beginning.

I shall attempt this in TB and see how it goes. Many thanks for your comments @eastgate

Hi Mark,

Great tips as always. Question: if one used link types to define the relationship is there a query that could be used to find those notes with specific link types?

I for one, have certainly underused link types for this reason in my use cases in the past.

Many thanks

Is it possible to import an attribute value? Could I have 100 notes using the Person Prototype and then import say a telephone number into the $Telephone attribute for all of the 100 contacts from a CSV?

Absolutely, a number of action and export codes are (usually as an option) sensitive to named link types.

Action code can createo r remove links, see this list of pertinent actions.

Agents or actions can query the existence of links using linkedTo() and linkedFrom(). There is also links(), which is also essentially a form of link-based query.

Side note to self: somewhere in the various support docs perhaps we need a better summary page relating to deliberate use of link types.

Using link types—as other than drawing labels in map via—is a bit chick-and-egg. They are essentially the only (non-visual) persistent accessible metadata for links. Again, unless used visually on a map, their application can seem to have little point until you want to investigate linkages, especially those running outside a single container (i.e. map).

At the same time, using link types at scale can be tricky as there are—as yet—not action codes to alter link types on mass. Currently, the latter involves deleting the existing link (of the ‘wrong’ link type) and inserting a new one of the desired type. However, that really only works for basic links and not text links as action code has on access to link anchors. The new ziplinks text-link-creation method doesn’t support setting link types.

Link types, by historical lineage, have a start in enabling argumentation across the hypertext as is attested to by the set of default link types created in a new TBX. Be aware you can delete these and/or add you own, though at this point is it worth checking new user-added link types show up in the document before using them in things like action code (i.e. ensuring the master table of available link types had properly updated).

Just as a side note, I think you mean “CRM” not “CMS.” This topic drew me in because I do use TB as a CMS, but have not the former.

The opening post actually refers to ‘CRM’. In that light, the thread title’s use of ‘CMS’ might be an unintentional typo. If this narrow case is true, left me know and I can edit the thread title. :slight_smile:

Actually I think it’s a bit of both. Initially I thought in terms of a CRM, but then I really want to expand the TBX to manage policy docs, room hire, managing depts and so forth. My intention moves it a little further from Customer Relations Manager although at the moment it is clearly a CRM! Apologies for the confusion! Perhaps a title of, “Using TBX as a CRM/CMS” would be more appropriate?


1 Like