MainBoss relationships are a way of connecting units with people and with other units. Relationships can be used for many purposes...but since they're so general, it may not be easy to see how they can be applied to solve specific problems. Therefore, we're going to look at a some examples, as a way of helping our customers use relationships to their fullest advantage.
Relationships let you deal with situations where there is a noteworthy connection between units. For example, suppose a building has a dozen hot water heaters, each of which serves four bathrooms. If a particular bathroom isn't getting hot water, it's useful to know which heater is associated with that bathroom and where the heater is located. To do that, you would create a relationship that showed the connections between bathrooms and heaters.
For every type of relationship, MainBoss asks you to specify two phrases. In the example we've just discussed, the phrases might be "heats water for" and "is served by". MainBoss then lets you use these phrases to set up relationships, as in
Heater A heats water for Bathroom B Bathroom B is served by Heater A
The unit record for Heater A would list all the bathrooms "served by" that heater. The unit record for Bathroom B would list which heater "heats water" that bathroom. This sort of information can help workers avoid wasting time and effort following plumbing pipes in order to see which heater serves which bathroom.
Units can have any number of relationships. For example, consider a rental unit in an office building. It might have the following associated with it:
You may be surprised at parking spaces being included in this list. Different maintenance departments may take different approaches, but one possible rule of thumb is this: if the tenant of a unit could legitimately complain some place or piece of equipment, that place/equipment should have a relationship with the tenant's unit. Thus, if you think it's ever possible that a tenant might submit a complaint about his/her allocated parking space, it might be useful to show that the space is associated with the tenant's unit.
MainBoss 3.4 also lets you establish relationships between units and people—specifically people who appear in your Contacts table.
Here are some examples of unit-person relationships:
As with unit-to-unit relationships, unit-to-person relationships give you a chance to make note of anyone who might be useful to contact in connection with the unit. By putting this information into MainBoss, you can save time for you and your workers if they ever have to talk to someone about a unit. This is particularly useful in case of emergencies!
Maintenance departments often discover problems that they aren't allowed to deal with until someone outside the department gives the okay. For example, a property management company may find some problem that affects a tenant who will be charged for the cost of repairs. In this case, you likely need the tenant to sign off on the job. If the problem is an emergency, you may need to contact someone with signing authority, even if it's the middle of the night.
This means it's very useful to have "on-call" lists associated with units. Such a list gives contact information for one or more people who can be called if the unit has problems. In MainBoss, you can create such a list using unit-to-person relationships.
Remember that relationships are defined with two phrases. In this case, you might have:
PERSON "can be called about" UNIT UNIT "has the following on call:" PERSONThis information will be stored in the Relationship section of the unit record and the person's contact information record. Thus if you want to find out who's on call for a particular unit, you can just check the unit record. (Note that with multi-select dropdown boxes, you can start from the Related section of a Contact record, and quickly establish relationships between the person and many different units.)
If several people can be on call for the same unit, you can simply create multiple relationship records:
John Smith "can be called about" UNIT Mary Jones "can be called about" UNIT ...and so on...If there's a preferred contact order, you can simply create an ordered sequence of relationships as in:
"should be called FIRST about" "should be called SECOND about" "should be called THIRD about" ...and so on...
If you have a large number of contractors, you may wish to keep track of which one usually works on a particular unit. For example, consider a fast-food chain with restaurants in many towns, all of which have their maintenance needs managed through a single MainBoss database. In each town, you've arranged with a local plumbing contractor to deal with plumbing problems in the local restaurants. The central maintenance office can keep track of which plumber handles which restaurant by setting up an appropriate unit-to-person relationship:
PERSON "is the standard plumber for" UNIT UNIT "has its plumbing needs met by" PERSON
Some organizations (e.g. municipal governments) prefer to cycle through contractors in sequence so as to "spread around" their business. In this case, you could set up relationships for all the contractors you might hire to work on a particular unit, as in
John Smith "is the FIRST plumber for" UNIT Mary Jones "is the SECOND plumber for" UNIT Chris Page "is the THIRD plumber for" UNITWhenever the unit needs work, you can look at the most recent work order on the unit, and then pick the next contractor in the cycle. For example, if Mary Jones was the most recent contractor to do work on the unit, then Chris Page is next in the rotation.
In some jurisdictions, workers need to be licensed or certified to perform certain jobs. For example, a person may need an electrician's certificate in order to do some kinds of electrical work. In MainBoss, you may choose to keep track of this information using Trades, but here's an interesting alternative: consider a license or certificate a unit, and use relationships instead.
For example, you could create a unit named "Class A Electrician's License". You could then establish a relationship like this:
John Smith "has a" Class A Electrician's License Class A Electrician's License "held by" John Smith
One advantage of this approach is that you can go to the Related section of John Smith's contact record and see all the licenses he holds. Another advantage is that this approach makes it easy to indicate when John needs to be recertified: just create a preventive maintenance unit maintenance plan for the license, indicating when the license must be "serviced" (i.e. renewed). When the time comes for John to get recertified, an appropriate work order will automatically be generated, telling John to "work" on his certification.
You can even use attachments on the license unit to store associated information, e.g. a digital copy of John's actual certificate.