Emailing a Timekeeper in Elite 3e

There a few ways to email a Timekeeper in Elite 3E. Which one is best for you depends on how you manage onboarding, and user management.

The Timekeeper archetype in Elite 3E does not have an 'email' field. That leaves a question as to what email address should we use for sending an email for a notification of some sort. As I see it there are a few options with none standing out as the best in all situations, but one may work for you. I mention 'User' often in this post, as in my firm the User archetype's email field and network alias are very dependable, with the latter being absolutely necessary in order to use single sign on.

Add a new field to Timekeeper

One of the seemingly easiest things to do is add an attribute to the Timekeeper archetype, object, and timekeeper maintenance form. From then on it is as simple as querying for that field in the Timekeeper table. I think the downsides to this approach are maintenance and the fact each Timekeeper gets one email address only. The benefit is simplicity from querying through OQL and SQL. Other benefits include simplicity on the security tree; it becomes quite trivial with the assumption that whoever updates the Timekeeper record can update the Timekeeper email field. However, if you are utilizing the Entities properly, you may end up with email addresses that are out of sync with each other. If you map users to timekeepers by some means, again you risk having some data out of sync. Addresses being out of sync can be easily mitigated with regularly run automatic reports. At my current firm such reports are run daily using Intapp's Integration Builder. I've got that same rule creating Helpdesk tickets in our firm's ticketing system for prompt correction.

Use Timekeeper Workflow User

Somewhere between 2.6 and 3.8 Elite has added a field to the Timekeeper record called 'Workflow User' which allows the Timekeeper record to map to a user directly. I haven't fully explored the Workflow engine in 3E. I've attended some sessions at Vantage and am left wondering if I want to bother digging deeply into 3e's workflow processes, or stick with Intapp for our workflow needs. I might give the Workflows a little more room to mature. Although this field seems very promising and I think it may just be the best choice to map back to a user I have a hunch that I may want to be able to use this field as a way to allow some interesting things around providing an assistant a temporarily measure to act as their lawyer for workflow purposes. That might also be a nightmare of an idea. The existence of this field, however, does point out that instead of adding an email field, we could add another field which links back to a user in order to map to an email address (named 'Timekeeper User' or similar). In our firm, the Helpdesk staff manages the User aspects of Elite, so it takes the burden off of Finance for keeping up with management of email addresses.

Use the Entity

The Timekeeper record does map directly to an Entity. I suspect the Entity archetype is under utilized at many firms, but I think it is one of 3e's best design choices. Entities allow 3e to map a single Entity to multiple other archetypes such as Client, Payee, Vendor, User, Timekeeper or Related Party. If the integrity of the data is good, we should be able to link from a Timekeeper's Entity field directly to a User's entity field to get to our User record which allows us to obtain an email address. The real issue here is that a single Entity can be linked to several Timekeepers and several Users, knowing which one we truly want in this many to many style mapping can be difficult to impossible if the business rules don't prevent erroneous entries. Again, this is mitigated through some automatic rules checking for data integrity. Another minor annoyance here is that entity is read only in the Timekeeper record (out of the box anyway).

Use the Entity (option B)

If the Timekeeper has an Entity set, we don't necessarily have to go to the User record to get the email address. We can use the Relationship child grid in Entites, with a 'self' on the Relationship field, add a Site, then a site email. If managed correctly this can work, but we do end up with Site types, and Site Email types, all of which can add a great amount of flexibility, but also causes for some more complex OQL and SQL calls to get the data we want. Views in the database can assist, however, we're adding some complexity and technical debt during upgrades, testing and general troubleshooting. I've found that throwing custom views into the mix generally causes some negative issues particularly as personnel changes, consultants get involved and are not provided specific instructions as to what custom features are available. Support from the vendor also becomes impeded by the addition of custom views.

Use User Timekeeper Mappings

An option which I was surprised to see on my first day being exposed to 3e was using the 'Default' checkbox on a User Timekeeper mapping to indicate that this user is this Timekeeper because the "Default" checkbox is checked. I personally dislike this approach (although haven't yanked it out after 5 years) as the timekeeper mappings change frequently and occasionally are left with a user having no default timekeeper set. We have rules running to flag such a scenario to the Helpdesk automatically, but it would be more ideal if we didn't need to. I suppose we could write some logic into the User object to make sure a user has at least one default and that there is at least one user-timekeeper mapping set (next week?). There are upsides to this for me in that our code base has been depending on this situation for years, everyone is aware of it, it's fairly easy to query through OQL and SQL. There are some downsides here as with any other method that depends on using the User email address; it assumes a timekeeper has a User. We have a minimal number of timekeepers who are on specific files that are not Users of Elite but their time is tracked. As it is minimal, it doesn't currently cause much of an issue as we are not routing anything to them, alerting them budgets, or have any other current need to notify based on data in 3e.