Abililty to change field names (Display As)

This feature is available in RE and it helps eliminate confusion by allowing organizations to customize fields based on their unique terminology.

  • Danny Reader
  • Mar 10 2016
  • Reviewed: Voting Open
  • Attach files
  • Guest commented
    21 Oct 16:58

    Especially for organizations with RE, being unable to change the display name results in unnecessary confusion.

  • Andrea C commented
    21 Oct 10:21

    Having the ability in NXT to rename a field that already exists instead of using a custom field would be very helpful. For our example, we have Nickname and Maiden name, but in NXT they are Preferred Name and Previous Name. This causes much confusion as our Fundraisers now assume that they should always be using the Preferred name to address a donor, when in our historical data capture this information is just an alternative name, not a preferred.

  • Devan Caton commented
    31 Jul 15:24

    Fields from the Bio/Org 2 tab of constituent records in database view have now been made visible within the RENXT web view. The web view shows the original names of the fields, not what they have been relabeled in the DBV. Please add the functionality to allow the field configurations, like renaming, to carry over to web view. We need consistency between web and DBV. Additionally, the configurations should carry over for fields that have been hidden in DBV to be hidden in web view as well.

  • Maya Rosman commented
    26 Feb 19:33

    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.

  • Rachel Newbury commented
    November 04, 2021 11:47

    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.

  • Jarod Bonino commented
    January 24, 2019 20:42

    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.

  • Matthew Nareff commented
    January 24, 2019 18:41

    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.

  • Jarod Bonino commented
    January 24, 2019 17:11

    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

  • Tom Eastaway commented
    January 24, 2019 11:33

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

  • clare watson commented
    September 26, 2018 12:14

    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.

  • Jen Claudy commented
    March 10, 2016 16:02

    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.