Tracking Previous Consultants

[Mark HHP]

Hey guys.

If I have a Client object which is a peer of a Consultant object, how could I track previous Consultants if the Consultant changes? So if a Consultant gives a Client to another Consultant, I'd like a Previous Consultant instance with perhaps a timestamp? The goal would be to open a Client and say, ok, this Client is handled by Consultant X but was previously handled by Consultants A, B and C.

Would a separate object be the best way around this? I'm redoing my CRM from the ground up, trying to fix all the things I messed up/forgot the first time around. At the moment, my Client has a text field called Previous Consultant and I manually type in the previous name whenever I switch a Consultant out.

Any better ideas?

[tford]

Hi Mark,

The approach really depends on what you want to do with it. Here are a few questions that come to mind:

1) Do you want to allow for multiple previous clients or just one?
If just one, simply having a rule which saves the previous consultant's name to a calculated Plain Text field could suffice along with a timestamp.

2) Do you ever want to be able to delete a client?
If so, a reference attribute could be dangerous as you could loose some of that history info if you are not careful with the delete process.

3) Do you need to reference any of the attributes of the previous Consultant?
If so, clearly having a reference attribute where you can shortcut the previous consultant attributes would be helpful.

[hpl123]

Mark,
Another idea is to create a "History" BO that basically is a log of changes in the Client or Consultant object (you could then for example have a tab in the object called "History" where all historical "records" are kept. A History log could then be changing consultant, transferring client to another consultant etc. etc. and this solution could also be expanded to cover other uses like for example user changing some attribute, consultant communication with client etc. etc..

[Mark HHP]

Ah Tom and Henrik, you legends.

My boss tells me now he'd like 2 previous consultants logged. So maybe a combo of both of your suggestions?

If I had a History BO, what would the rule be to create one on change?

If Client.Consultant WAS CHANGED Then CREATE History WITH History.Client = ThisClient, History.PreviousConsultant=ThatConsultant

I'm never sure how to refer to the previous object.

[BenHayat]

Tom & Henrik covered it all. The Log history is the key and as Tom said, be careful how you build the connection between client with history object. An Owner/Owned can wipe out the log if you delete the client.

[tford]

I actually use a combination of the two. I use time stamped log files extensively & often find that they come in very handy later for either system problem solving or meeting requests of the users who didn't initially know all of their historical data needs up front. Few do.

I usually include peer references to the BOs being logged & also often copy certain data out of the referred BO to store in log BO attributes. This gives the best of both world .. access to the referred record if it still exists & key data if the referred record has been deleted.

[Mark HHP]

Yeah, I agree. Considering my first experience with Aware (coming from a graphic design background) was building a fully featured CRM with no real test time, I'm taking the time now to rebuild it, make sure my references are all correct, my objects are all where they should be and all my rules are set to stop things happening not try fix them once they do.

As per my previous question, how do I refer to the previous consultant? Would something like this be ok?
If Client.Consultant WAS CHANGED Then CREATE History WITH History.Client = ThisClient, History.PreviousConsultant=ThatConsultant

[hpl123]

Mark,
It depends on how your app is setup and is not as easy as a single rule if you want to implement the History BO solution. Here is a couple of loose thoughts.

- Create a History BO with the attributes you want e.g. Date etc.. I would probably create a ChangeLog attribute in the History BO which would be a plain text attribute where a line of text/comment could be added automatically by a rule when a special event has occurred (for example: "Consultant change for client X (Old consultant: X. New consultant X.)". With this changelog solution, you could use the same object for many different things / types of logs.

- Look at the WAS ADDED TO and WAS REMOVED FROM rules in the user guide. These rules also has additional context prefixes you can use to work with multiple instances in context (Added, Removed) and then you could refer to RemovedConsultant and AddedConsultant for example when creating the History log instance. Again, multiple rules would be necessary to cover all of the different scenarios (and how these rules would look depends on the setup of you app for example relationship type/properties between Client and Consultant etc.).

- You can work with the BO rules of the Client or Consultant object to create the History log OR you could possible use a process to do the consultant change and in this process you could PICK new consultant and then also create History log etc. etc..

- If you do as Tom suggests, having a relationship between History and for example Client as well as information in the actual History log (you don´t need to have this relationship though and if you´re unsure as how to set it up, skip it), be careful as Ben points out with the way you delete consultants, clients etc. so the delete operation don´t affect the logs etc..

[RentProperty]

I have a bit of a different approach in an application that I recently built for a swimming pool company. Basically a pool can only have 1 Current Account Holder at any specific point in time, but you also want to be able to see a list of all the account holders that was ever linked to this pool in some way.

So what I've done is to create 2 Relationships from Pool to Account Holder. The one is a peer relationship with multiple allowed OFF, called Current account holder.
The Other is a general Multi Relationship Called Account Holders.

So when I Add a new account holder I ask the user if this is the current account holder. IF YES then I Do:
INSERT AccountHolder IN Pool.CurrentAccountHolder
INSERT AccountHolder IN Pool.AccountHolders.

This way you have easy reference to the Current Account Holder, and you can have Shortcut Attributes on Pool (In Your Case Client) to CurrentAccountHolder.Name, CurrentAccountHolder.Email etc. as there can only be one.

So if you want to change the CurrentAccountHolder You just do a Pick or Create and INSERT into that Relationship.

So something like this combined with a History Object With Consultant Change Dates Should cover the spectrum of what you need to keep track of.

Just my 2 peas. Hope you all have a blessed Easter Weekend!

[Mark HHP]

So many options! Thanks a lot, guys. This helps with my understanding as well as the execution. It's not always the best when you are given the answer with no real explanation into the whys.

You guys are awesome.