Employee Tracking within Raiser's Edge

Mercedes McCayRead · July 2017

I'm wondering if anyone has a best practice for tracking employees within Raiser's Edge? I inherited our database and employees are currently tracked in numerous ways (using EMP code on Bio 1, as an attribute, and as a constituent code) and it is very difficult to report on employee giving or really anything related to employees because I have no guarantee that I'm getting all of them based on how many options we have for where they're being tracked. Is there one specific location that anyone uses over another and any pros/cons for where to track them? Thanks in advance!

Karen Stuhlfeier · July 2017

I have always used constituent code. When they leave I change the code to Past Faculty/Staff. I prefer to do that instead of needing to use to and from dates when reporting. I don't really have any need to know the dates that they were here for my purposes and that information is kept by HR. All of my participation reports are based on constituent codes. If you use a gift code you have to enter it every time they make a gift. That seems like too much work to me.

Mercedes McCayRead · July 2017

Karen, so you don't use the date fields within the constituent code? I'm also working on cleaning those up (we have 50+) and have been debating between using dates vs. using different codes (employee, former employee).

Melissa S Graves · July 2017

I prefer consttuent code. When I use cons code I definitely have current employee and former employee and use dates.

My second choice is attributes. Then I use only current OR former but not both as it is too hard to query on otherwise. Dates would then only apply to dates they were current.

Frankly, relationships get far too cumbersome on your org record to manage well.

JoAnn Strommen · July 2017

We use gift code filed to track ours. Easy to query for reporting. Has worked for us.

(We also have 'staff' constituent code and use to and from dates. Can make a case for either way-changing to former, not bothering with dates.)

John Cioni · July 2017

We use consitutuent codes Employee and Former Employee. It's difficult enough keeping up with everyone coming and going but I have thought about adding in end dates as well. I find it much easier to track employee giving with a constituent code and the appeal associated with the campaign.

Alicia Van Straten · July 2017

We use constituent codes with dates. When they leave we use an end date and add a new constituent code of retiree as we also actively solicit our retirees. We also store their Employee ID in the Bio 2 tab, customized one of the fields. It helped with de-duping the John Smiths of the world. We have a pretty active employee giving campaign (raise about 100K) so we also track all their gifts with the appeal of 20xxEmployeeGiving as well.

Karen Stuhlfeier · July 2017

We don't use the end date unless they are deceased. We do put a from date in, but that isn't necessary for our reporting.The code reflects who they are to our organization. I think that it's much easier to do reporting that way.

Jen Claudy · July 2017

At my last org, we had the Volunteer Module, and I stored employee information there. I also used a Constituent Code (primary for current employees), which is automatically carried thru as the Gift Constituency and was used in some of the reporting we did. Occasionally (often enough that starting fresh with data from HR would have been a bigger pain), I was asked to pull reports showing historical data on employee giving or calculating percentage of employees at specific points in time who gave...and sometimes that request included which department or which location they worked in at the time. So I liked to keep track of as much data as I could reasonably handle. Constituent Code was my go-to place, though, unless I needed additional information. I tended to use dates rather than options of Former, although if you're regularly using the Constituent Codes, you may find that it saves time to not have to include "Date To equals blank" every time.

If you use Former options, my personal preference is "Employee" and "Employee - Former" so that alphabetically they appear in the dropdown next to each other. Same for Relationships..."Spouse" and "Spouse - Former" is my preference. Also easier to change with one press of the down-arrow key!

Gina Gerhard · July 2017

We don't do it with constituent codes or attributes - we do it the harder way through relationships.

We have an organization record for our organization - and we create employee relationships to that organization.
- This allows us to record all sorts of additional information about their employment - their title, position, additional attributes related to their employment - and we can make them former employees and them reinstate them as current employees if they rejoin the organization.
It does make querying a bit more cumbersome
- You query on everyone who has an organization relationship to SPECIFIC RECORD=our org and whose RELAT=Employee (or Employee-Former) - to find only current, only former, current and former.

Mercedes McCayRead · July 2017

That is interesting. We have some constituents who have "relationships" on their record and I wasn't really sure why, but apparently that's how they used to track our Board Members back in the day before someone switched to using constutient codes. Thanks for the answer/insight.

Holly Sailers · July 2017

Gina Gerhard · July 2017

Holly - Glad to hear that someone else is doing it the same way --

The only area that sometimes gives me heartburn with this approach is when I actually want to query on 'Former Members' -- when I actually want to find former board members that are NOT by chance serving again as current board members.

If you query on 'Member-Former' (or however you have your relationship defined) you may pull in people who were formerly on the board but who have come back on and are currently active 'Members'.
If you truly want to find only former board members, you have to do a merge query and subtract out anyone who is currently a board member from the former members query.

If you know that no one has 're-served'' on your boards then it's not a problem -- but we have many members who have come back onto our boards.

Christine Cooke 2 · July 2017

I have always tracked them with a Constituent Code. They also have a Relationship that is Primary Business Info, which is our Org with their start and end dates and their title. And if their title changes (taking a new positioni at your Org) then there is an end date and a new relationship is added with the start date and the new title/position. Easy to pull reports, easy to track who is current and former employee. They have always been in the top 3-5 (as in hiearchy) groups that have their giving tracked so I cannot imagine burying that info anywhere. Front and center is the way to go in my book.

Karen Hartt · July 2017

Hi Mercedes,

We use constituency codes, Current Staff and Former Staff. We tried using end dates, but folks who weren't heavy users of RE were having issues with the date fileds. I wanted to keep it simple. We also link them with our orgainzation as a relationship and use the end dates for employment there.

Daniel Bayer · July 2017

I liked the way we did this at my last org: Constituent Codes for Current Staff and Former Staff were used, without dates, which were tracked in the Primary Business relationship record. It meant a bit more work when someone left or came on board, but I liked how versatile it was, and it also made sense to me - obviously the Business relationship is where you should keep track of dates of employment!

Personally, I like using dates on Cons Codes, but I know it can get too cumbersome for some people. This was a good compromise.

Heather MacKenzie · July 2017

Partially due to a prior database's reference to employees coming into the Attributes tab, we use both Constituent Code and Attributes. The constituent code is employee, and we enter start and end dates (start date is typically the start of our relationship with them, and end date is when the leave our org) and then the attribute is where they work. We have 2 different business locations, and 6 different company names that come into play when we are talking about employees, so that's what the attribute is recording. When someone leaves the organization, they switch to an attribute of former employee, still location coded, and the date range goes into the comments field. The constituent code gets an end date and their primary constituent code becomes individual at that time.

We use the gift consituent code all the time in reports and queries, which comes from the primary const code on the Bio 2 or Org 2 tab. Changing from Employee to either Former Employee or Individual, as we do it, allows you still to track what that person gave while an employee, but also allows for what was received after the person has left our org.

When we think of it, we'll add a relationship between employee and employer, but since we currently don't use that to query or report build, it's incomplete in my database. We do look, when someone leaves, and change it to former employee and employer, but that's about it.

Brittany Farmer · July 2017

Hi Mercedes! At my organization we use a couple of areas to track employee information. First, we use constituent code. We have Employee and Former Employee, and we enter the Date From/Date To as their employment dates. We get terminations updates from our HR department so we know when to switch someone over to Former Employee and add a Date To. We only enter employees when they've donated, so we're not importing all new employees as they come on board with the organization. Therefore, we know at any given time we don't have ALL employees in the database, but our philosophy is that we're only worried about the employee donors. Those are the ones we want to see anyway.

We've repurposed the "Ethnicities" field to use for employees' departments. We've also repurposed the field directly above that to use for the employee's number, which is what is used for payroll and all sorts of other things in the organization. We have access to real-time HR reports that provides us that information, when entering a new employee constituent. We do not use attributes for employees. We find that the combination of constituent code, employee number and department is enough to get us what we need.

Dwight Au · July 2017

I like most everyone use Constituent Codes as much as possible. But seeing that this is a big organization we dont always get notified of people leaving. Usually once a year we get updated by asking for a list for the Employee Giving Campaign. What I also did is on the Bio1 tab rename the SSN Field to EID (Employee ID) so that number goes there. So if they are are or have been an employee you can just query on that field. It's a quick way to tell about employees.

JoAnn Strommen · July 2017

Really liked the idea of re-purposing the SSN field for the employee ID. So just imported them only to run into a glitch. So sharing this word of caution.

Our employee IDs are based on name, not #s. SSN field cannot handle an upper case "X". So ID containing LaCROIX and BAXTER didn't import. Went to knowledgebase and learned no capital "X"-try with lower case. So changed first one to LaCROIx. Accepted and will still pull in a search. Tried BAxTER. Upon saving it converts to XXxTER. So won't work.

Liked that field as it's on Bio 1. Will have to consider some other field like Religion if I want to move it off attributes.

Dwight Au · July 2017

Sorry JoAnn should have mentioned that about my Employee ID's are all numbers. Of course not allowed to ask for SSN numbers so wanted to use that field for something.

Gina Gerhard · July 2017

One thing we did is to create a 'fake' phone type to hold this information. Phone formats can handle text data.

That way it's very visible on the front screen and you have good access to it.

Christina Bunch · January 2018

This thread is very helpful for our Employee Giving Campaign. Thanks for posting this!

Alicia Barevich · January 2018

We, too, have a few places for employee coding, but the one thing for sure is their Business Relationship, and then we have attributes under that for further designation on what type of employee they are/were. Any other places for tagging are secondary. At my prior organization, that was also where everything was coded.

Christine Cooke 2 · January 2018

Have always used this method wherever I go:

Constit code of Employee Current or Employee Former (when they leave)

Relationship to your Org (which has it's own record in RE) with their start and end dates, position listed there. If they get promoted or change departments I enter an end date and add a new relationship for the new position.

If you need to keep track of what Department they work in I would go with a Constit Attribute.

You can easily pull giving reports, if you have a need to know giving by department you can drill down on that one, some orgs have challenges between departments for participation so that's when that comes in handy.

Michelle Kolak · January 2018

We use both constituent codes and relationship attributes. I have 4 constituent codes, FT current, PT current, FT past and PT past. I have attributes for FT Faculty, PT Faculty, FT staff and PT staff in the attributes on the relationship. The attributes also have the department in a dropdown and I put the title in the comment field. This way, if someone has two positions, I can track this, as we have had employees who may teach part-time and also hold a part-time staff position.

We have worked it out with HR and payroll to get monthly files of current employees. I also get daily updates of when employees leave. We finally convinced them of the importance of this when we were told that we needed to send out solicitations but had to exclude our PT faculty because of union negotiations.

When I first started getting the files, it was a huge pain to import, but I figured out an easier way. Instead of comparing the file to what was in RE, I compare this months file to last months file in Access. If there are any changes, then I can just import/update the new data. We have just under 2k employees, and I was able to update everything in about 3 hours.

I have an attribute for alternate IDs. There are several systems I get data from, so I add their ID if they have one.

Heather MacKenzie · March 2018

Our employee id numbers go into the record as an alias, so we can look them up by the number, and also considering what Joanne mentioned - we were just moved into a new software in January for payroll and h/r and we didn't know ahead of time if we were switching to an employee identifier that would have any letters in it. Alias lets you enter both letters and numbers.

Christine Cooke 2 · March 2018

I have always tracked employees with a Constituent Code and a Relationship. Our Org has it's on constit record. Each employee has a relationship to the Org where their start and stop date is kept along with their title. And if they change positions, one relationship has an end date and then a new relationship with the new position/title is added.

By having them each have Current or Former Employee as a Constit Code, that tracks all the way through to the giving reports (as long as it is their primary constiti code) Happy housekeeping!

Tiffany Dickel · January 2021

How do I rename a Constituent Code?

JoAnn Strommen · January 2021

Your ability to do this may depend on your user rights.

In Configuration > Tables > Constituent Codes > select/open the code you want to edit. You can make any changes in the box that pops-up.

This will change the code currently on records as well as future use.

JoAnn Strommen · January 2021

Tiffany, I see you pretty new to posting in the community. Welcome!

After I replied I noticed this is in the midst of a thread that is several years old about a different topic. If possible you'll want to start a new discussion for a new question. I know getting the option to do that can be tricky after you've been searching because I couldn't get the option the other day when I was searching and then needed to ask question when I couldn't find post. If that was your experience too, maybe Crystal BruceElizabeth Perron could clarify where/how we need to be to have that start new option.

Employee Tracking within Raiser's Edge

Comments

Categories