nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Adding our own employees to RE

Michele Mandala

Is there a “best way” to add our own employees to RE, and have their primary business (our organization) linked properly?

Currently, the organization has multiple records in RE (Yikes!), and before I start cleaning up, I'd like to get an idea of the best way to get our own employee records linked.

Should our own organization have a record in RE?

Your thoughts/ideas will be much appreciated.

Thanks in advance,

Michele

Find more posts tagged with

RaisersEdge7 Databaseview

Comments

Ray Bergman

Moving this topic to the RE community for better visibility.

JoAnn Strommen

Welcome to the BB Community, @Michele Mandala.

I would recommend one org record (if possible) for your org and linking thru relationship each employee to that record.

Each employee could have a relationship to a non-constituent but if you are ever querying or want to pull a list based on relationship you would need to be sure each entry was entered/spelled exactly the same.

Do your employees already have records in RE? If you are adding them en masse I would use a constituent batch with relationship defaults.

Another option would be constituent code of “Employee”/"'Org' Employee."

Part of deciding the best option for data “in” depends on needs for data "out."

Just one users opinion.

Dariel Dixon

I think having a master record for employees is probably a best practice for certain. Obviously, having multiple records for the same organization serves very little purpose and causes a lot of confusion. If it was an outside organization, you would probably have added the employer information without hesitation.

That said, I'm not a big fan of adding people to the database until there is a reason for them to be added, and I don't know if employment as a default is a reason unless there's a business purpose or for record keeping.

La Donna Borth

Welcome to the community, @Michele Mandala

If we add an employee to RE, we use a Constituent Code and attribute to identify them. At our organization, we add those employees who donate. More recently, new staff have been encouraged to add themselves to RE by registering for our website (BB NetCommunity). Once they have, they begin receiving emails, including a monthly eNewsletter.

Development staff receive mailings. All other employees only receive mail if they donate.

Barbara Kunkel

We handle employees in the same way as @La Donna Borth . We add employees to RE with a Constituent Code only for those employees who donate. We don't link them to an organization record in RE because of the Constituent Code. Before you add all employees, think about why you want to add employees to RE. Also, think about how to maintain data integrity with employees such as adding new employees and how to handle terminated employees. This is time consuming depending on the number of employees.

Madeleine Holdsworth

Agree. We add if they make a give, and also add employees if they ask to be added, because we pull emails from RE for email blasts and newsletters they want to receive. We attempted a few years ago to add all staff and it was a nightmare keeping up with addresses, adding people, people leaving. It's way too time consuming. Our HR and marketing now handle that.

Christine Cooke

Everywhere I've ever worked there has been a Org record for the org. And all employees had their own constituent record that was linked to that Org record through Relationship. Of course, there has been a lot of clean up for inconsistencies – but it's worth it. The Employee has their won constituent code of Employee-Current or Employee-Former as appropriate.

Minimally the employee has their name, their email at work, their relationship link to the org with their title/position and start and stop date(s), and the relation/reciprocal fields. Even better if you have their home address, cell phone, personal email, spouse/partner.

Yes, it is something else to maintain, but I look at it as an item on my annual housekeeping list.

It does not matter whether they give or not. Some orgs make a point of asking employees to give back to the org and others do not. The places I've worked have always asked.

Our department is asked for email lists, mail lists, name tags etc. for the community (meaning our org's population) and so having the employees ensures everyone is included.

Faith Murray

We've found it beneficial to add our employees and to have our Org listed in a record. We don't necessarily link them under Relationships, but all are marked with an appropriate constituent code for filtering during mailings.

Even if you don't plan to solicit employees (we don't), it can be nice to have them ready in case you want to invite all employees to an event or distribute employee e-newsletters. I've read nonprofit articles talking about how, ideally, every employee should be an ambassador of your org - be able to spiel out your mission and current projects whenever a visitor asks. Including them in your e-newsletters, and welcoming them to mingle at forward-facing Open Houses, is a great way to foster employee ambassadors and build unity in your org.

Amelia Ketzle

We have a bridge built between our HR system and our alumni/donor system which adds new employees and updates/terminates existing employees on a weekly basis. We found there was a lot of demand for various types of employees to be added to our system as potential prospects or people who might have been involved with Actions and therefore might need to be linked. A couple of years ago, we hired a development/gift officer to cultivate within the campus community, so this person really wanted this data readily available. Also, since we do track employment for our alumni/donors, we would have been adding their employment to our organization piecemeal and it would have been inevitably inconsistent, so we decided it was worthwhile to have a direct link from the HR system to do this for us.

We did not bring over every piece of detail or even every single category of employees, but mostly they are now all in our system and all current. We add a Constituent Code of either Employee-Current or Employee-Former as appropriate (the interface updates this if they are terminated). We create an org record for each distinct department within the HR system, and those departments are all related to each other as appropriate, too. There is a parent org for our overall university (SIU).

We also pull over any contact information present in that system, and if the employment has been terminated, we add a Constituent Attribute to reflect whether they are now a retiree or an ex-employee. (This allows us to include retirees in departmental newsletters/invitations, but not include ex-employees who may have left on bad terms.)