Please do this. We depend on some of the ways we rename fields to make processes clearer for our staff. And, as things move forward, we need the ability to manage how fields display and change field names in webview (assuming all functionality will eventually move from database view to webview) and have the renamed fields show up with the renamed values in system tools like query and export as well.

Please link these 4 ideas as they are essentially asking for the same thing and together they have 85 votes.
RENXT-I-222: 48 votes
RENXT-I-1814: 21 votes
RENXT-I-2523: 9 votes
RENXT-I-2548: 7 votes

Thank you.

Thanks Matthew. I completely agree with your input and appreciate your feedback here. I think we still have work to do on making Custom Fields as usable and helpful as first-class fields. I also tend to agree that my specific example used a first-class field which I agree is not all that helpful in a modern world (one reason why you don't see Birthplace as a field you can add or edit in web view today).

I think what we've determined is that in RE7 we went overboard with first class fields that weren't particularly helpful for all (or most) organizations AND we didn't provide enough flexibility with the way custom fields are presented, organized, and interacted with. The result was a "workaround feature" that allowed users to simply rename fields which leads to non-standardized data (one organization using a field one way with other organizations using it in an entirely different way), which as I mentioned, is potentially another problem altogether. It does go beyond benchmark reporting. It also impacts the way we present info. If we decide to re-organize the default view of certain bits of information in our user interface, it does help to know what type of information is being shown in a given field. With re-purposed (not just slightly renamed) fields we lose any insight we have into what type of data is shown in that field. Which is again, fine if the field is a "Custom field", but not if its a first-class field that we may try to treat (or assume is used) a certain way.

All that to say I don't disagree with the problem here - Organizations have needs to track fields in ways that are unique (or somewhat unique) to their organization, constituent base, or vertical. And you may even want to display that information more prominently (or just differently) than we have laid out by default. That said, I do not necessarily agree that allowing users to rename first class fields any which way is a great solution to that problem. I think it leads to other fundamental problems that could be avoided if we focused on holistic solutions.

I really appreciate the conversation and dialogue though! It's extremely helpful in helping to keep us focused on prioritizing the right things as we build out product roadmaps.

I really appreciate the explanation behind why this is not something that's a priority but there are still a number of problems with that thinking.  We already have a pretty long list of attributes/custom fields and I hate to continue to add to them and have an even longer list.  And because NXT only shows 5 at a time and then requires you to go to the next "page" of attributes having a long list requires us to continue to scroll through until we find the field we're actually looking for.

I would also say that while some attributes/custom fields are pretty important they're not important enough to have the panel at the top and moving other's that are more important to us (giving, contact info, actions/notes) further down. 

Our organization is never (never's a long time I understand) going to want to compare the birthplaces of our constituents to the birthplaces of constituents from other organizations.  I would rather have a field that's not particularly useful to us and will remain empty changed to something we would want to track.

And as we've all discovered with the move to NXT, and all the great ideas contained in this idea bank, different organizations have different needs.  I guess that's something I would expect with a new, more intuitive, more user friendly product.

Hey everyone! Thanks for the votes and comments. I just wanted to chime in briefly to explain why this particular capability has not yet been prioritized yet.

Generally speaking, we've found that their are two main use cases for renaming fields in RE:

1. Slight renames to conform to an organization's established terminology

Example: Renaming "Fund" to "Designation"

This one makes a lot of sense and ultimately is something we want to support in web view. That said, the terms effectively mean the same thing in this case and it felt like a change in terminology that could be learned and didn't actually prevent activities from occurring or features from being used in the short term, so we have opted to continue moving over core capabilities before we empower users to make slight term changes.

2. Major renames that complete re-purpose fields in RE

Example: Renaming "Birthplace" to "Shoe size"

This is one we actually don't want to encourage. Instead, we'd prefer to see fields like this tracked as Custom fields (as opposed to renamed primary fields). I do realize that in RE7 relegating those fields to Attributes presented some navigation challenges, but we're working to break down that barrier but allowing flexibility in the way records can be organized and viewed today. For example, if you are tracking a number of important fields today as Custom Fields, you can drag the Custom Fields tile to the top of the record for easy viewing.

Re-purposing primary fields creates some unique challenges and limits our ability to provide value in terms of prescriptive behaviors. If you look at the Benchmarking reports that exist today, that might help explain what I mean. With those reports we are able to compare your organization's performance in many areas against industry aggregate data to help show where you are outperforming your peers (or underperforming against them). We think this level of prescriptive insight is invaluable for our clients and will really drive our next generation of prescriptive capabilities, insight, and reporting. Those things are only possible, however, when the values stored in certain fields are reliable and predictable.

If we take the example above - Imagine we found a way to provide value in showing a break down of donations received by donor birthplace (not something I can easily imagine being relevant, but just a token example). Our ability to compare and standardize that data is completely crippled if some orgs are using it as designed but others are using it to track shoe size, favorite color, or some other attribute that could have actually been tracked as a Custom Field.

I'm sure this doesn't solve everything for those of you that do find inherant value in the ability to rename fields, and I'm not suggesting we'll never make it possible in web view. I'm just trying to provide some insight into why this particular capability hasn't reached the top of our priority list yet.

Thanks,

Jarod Bonino

Senior Product Manager, Raiser's Edge NXT

A strange omission, but what we've come to expect from NXT. Rolled out before it was anywhere near complete.

Be great if this could be changed as really causing us issue, we use both versions and our amend items do not show ion NXT which is causing us issues.

Very, very interested in this...as well as being able to hide Fields that are not in use.  I would love to see most of the Config section from RE:7 move over with similar controls, so that we DBAs/Supervisor Rights Users can start to customize the NXT UI to be less confusing (showing Fields not in use, or Fields that have been repurposed with their "new" labels) for Fundraising staff.