We use the first approach, one profile type called “Faculty and Staff” and we tag them as appropriate.
The benefits to us are:
Only one profile type/template to maintain
Easier to switch someone from faculty to staff, and vice-versa
Sometimes employees are both, for example, an administrator that also teaches a class(es)
It is easy enough to use XPHP in the details template to design different layouts if necessary. But we really don’t differentiate them in our template. There are just some fields, like office hours, education, teaching areas, publications, etc. that generally only get used by faculty.
I honestly can’t think of any advantages the second approach would have for us.
The one exception to all of this is that we do have a separate profile type for our Admissions Counselors. Their needs were just so different that we chose not to incorporate them into the main fac/staff profile type. However, we do want them in our directory (which is generated solely from the fac/staff type). So, we create a profile in the fac/staff type, but just link it to their profile in the admission counselor type. This works fine, though sometimes I wish I had not done it this way.
Jon, in the case of Admissions Counselors, when you say you wish you hadn’t done it that way, do you mean you wish you had included them in the Faculty and Staff type?
We have separate types, but I wish we had just one. Especially when it comes to staff with faculty rank
Yes, that’s what I mean. It’s just extra work to manage 2 profiles for them.
Admission counselors have a lot of fields that are specific to them so it made sense to have a different profile type. But I could have added those fields to the fac/staff type, and maybe hide them with some backend css/js unless a counselor field is checked. Or something like that.
It’s one of those “not broke, don’t fix it” things though.
Agree with Jon on this, and that is what we do as well.
We use tags a lot to differentiate subsets of large departments, and balloons for sorting if a department wants to be hierarchical about it. A lot of our information (phone number, office, title, etc.) comes from our HR feed into the db that drives our searchable directory, and we have a data source in LW attached to that db to sync data to the profiles. We can override certain fields if we need to, which especially comes in handy when a person needs to show up in more than one group (we share the profile to the other group for that), and may have a different title, for example, in a different group from their main group. The data source is nice in that it keeps the searchable directory and the profiles in sync for basic data, and having it come from the HR feed helps us know when we might need to add/hide/remove profiles since we get a change report every day when the feed is processed. Departments often don’t tell us about personnel changes, unless they get a new administrative assistant who looks at everything on their site and wants to get their house in order!
That’s very similar to our setup. We sync a lot of the data from our external data source. However, we have a process on campus in which HR sends emails to a distribution list with notices of people coming and going. We are on that list, so we keep a spreadsheet of who is starting and when, so we can add their profiles, and who is leaving so we can remove their profiles.
