We need a unique ID field for the SSN. We you use this to help track our Alumni, especially those with same names. It helps us identify which one is the correct one

We use SSN for it's purpose. We have to have SSN number for federal tax credits.

Please we use this for EID # and is the unique identifier between RE and payroll. We import 10K+ gifts annually.

YES PLEASE this is a huge deal for us, and took us ages to get right. There needs to be a unique ID field that is not autogenerated and can be populated with data we input.

According to your NXT Features page - this field is not planned.

https://host.nxt.blackbaud.com/renxt-features-grid/

I hope this is inaccurate - there needs to be a mechanism for importing data to a record that users can control the field (while ensuring it's unique). We use SSN for employee ID at numerous organizations for payroll gift import as well as exports - though not actually using the field for social security data. Please update the features page so it's either undecided (hence the reason we are - and have been - voting on it) or ideally planned.

I understand that there are security issues with bringing over SSN's into web view, but as an educational institution, we do rely on SSN's at times. What baffles me is if you are able to have the security structure for SSN's and EIN's in Financial Edge, can't the security structure built around SSN field be used in RE too? Or at least the foundation of it?

I think what people are looking for is not necessarily the SSN, but a field that has the same "power" as the current SSN. I've used it - and recommended it to RE customers - for a few situations primarily because you can search for it in database view and because you can do imports using this ID.

Yes, seems like with other fields that are labelled differently, since many orgs have repurposed this, it doesn't have to be called SSN, but perhaps alternate ID or similar. Different from an alias in that it must be unique and should throw an error if a duplicate record is attempted.

Critical to our student system integration - and the field is indexed, preventing duplicates. Very important!

We use this at our organization for payroll deduct donations. This is a vital field and also ensures that when staff (we keep them in our system) are not duplicated if they have a name or address change and we try to enter them again this will prevent us from doing this. We absolutely need this feature in web view at some point.

Its being used by us frequently as a student ID and employee number so thats very vital to have it in web view.

Our organization uses this field to track student ID numbers and avoid duplicate entries. It is vital to our record keeping.

The need for this field is vital to our organization. We use it to store student ID information that is unique to each student to avoid duplicate records when importing. We also need this ID information when communicating with the College to verify we are dealing with the right student. We do not use the same systems, so it is imparative that we have the ablilty for store information in the SS field.

We also use SSN for our college ID (students & staff). We prefer this field b/c it is one of the fields allowed for import and because it only allows a unique entry per constituent, it flags us if we try to enter a constituent who's ID is already in the system. Our IDs stay with students even if they become staff, so it's a wonderful way to confirm that a person is the same and is not a duplicate. Losing this functionality in the move to webview would not be ideal.

Julie's suggestion is exactly accurate - many of my clients use this field for importing staff payroll gifts, and other imports - ability to search and see in web view is important!

Is there a timeline for this to be implemented?

It is one of the important fields to track the duplicate constituent. Highly recommended.