Does anyone use Raiser's Edge NXT for emails instead of Core pushpages?

Sondra Berry
Sondra Berry
Tenth Anniversary Kudos 2 Name Dropper Participant
in Blackbaud K–12 Education Solutions™ General Discussions
We have used the pushpage product in the K-12 modules (Core) for over a decade. Because there is very little styling available, we are looking at other alternatives. Does anyone use the email function in Raiser Edge NXT as an alternative for the Blackbaud K-12 pushpage product? If so, what are the pros, cons, differences?

Comments

  • Brian Pugh
    Brian Pugh
    Ninth Anniversary Kudos 1 Name Dropper Facilitator 1
    I've had to use both as we have our records in Core, but most alumni are in RE NXT. (We are in the process of trying to do a RE data cleanup, then import to Core and thereafter used Connect RE.)


    RE NXT Pros:
    • very strait forward interface
    • emails: choice of scheduling or immediate sending
    • easy to build an email list
    • no tiny rectangle to fight with as you create your distribution group
    Cons:
    • having frequently to use both core and RE NXT to send an email
    • haven't found an html editor yet to tweek regions
    Brian
  • Kim Hughes
    Kim Hughes
    Tenth Anniversary Kudos 1 Name Dropper Participant
    We use both. For the same general reasons as Brian. We have people in RE that we don't have in on though we did import our alumni. The bigger issue for us is the solicit codes that we don't have in Core for PushPage. We use PushPage for all general school information, but solicitations go through RENxt. And we also use REnxt for some of the random lists that created that you can't really do in Core very easily.
  • John Ronan
    John Ronan
    Tenth Anniversary Kudos 5 Name Dropper Participant
    Sondra,

    Thanks for asking an important question and thanks to Kim and Brian for their input.

    I have some comments and questions on all of this because it touches on some strategic issues I have been dealing with.


    [Warning: this is going to be a little long-winded because the topic is helping me distill many thoughts]:


    Isn't the whole "system" designed toward keeping current student [and parent] data in Core and keeping [and using] alumni information in RE/Nxt?


    In general, what we all want/need, I think, is:
    1. Existing alumni information for fundraising, etc.
    2. Current student/parent information for running the school
    3. Current student/parent information for fundraising, etc.
    4. Info. from #3 to change to look like #1 and reside there long-term as students become alums and parents become parents-of-alums.
    5. Also, since alums from years ago often become parents, we want to use the information they give us when their kids apply (current addr/contact info, etc.) to flow from #2 to #3
    When we converted from EE to On, we moved *all* of our alumni records [some 20,000] to Core and have been using Pushpages for alumni communication.

    This made me uncomfortable at the time because we were keeping the same information in two places, which, if not managed with some discipline, can result in the data being wrong in at least one of the places.


    I'm convinced this was a mistake, now that I am trying to integrate Connect/RE (C/RE).

    In a perfect Connect/RE world, all core records would be 'linked' to RE records and any changes to core records would flow over to RE via the Connect/RE plug-in.

    This, I think, imposes the "discipline" needed to avoid the pitfalls of data duplication.


    But I began the process of linking all 20,000+ records in core to their counterpart in RE.


    But because of C/RE's designed for one-way flow, from Core to RE, any changes that happen in RE would *not* flow back to Core. Moreover, once I started trying to link Core and RE records, I found that any Core information was overwriting the RE info.


    This is/was problematic because, for people who have graduated, our Advancement Office are the ones to manage that data as they are the ones who "keep up" with alums. Hence, any updates they may have done to alum records over in RE since we copied them to Core 3 years ago in our original transfer from EE would be overwritten by any [old, stale] Core info.


    Among other things, this results in some nastiness, for example, if there is *no* address or email in Core, but one in RE, it'll deactivate the one in RE.


    So my thinking is that we should do the following:
    • Use the RE/Nxt email facility for:
      • Advancement Office contact with alum-only people
      • Advancement Office contact with current parents and students for Advancement-type contact. [they would be in there via connect/RE]
    • Use Core's Pushpage facility for "current student" data for "current school" communication
    • Remove *all* alum-only records from Core. [alums who have since become parents would still stick around]
    • As new parents come into the system via applications, etc.:
      • If they don't previously exist in RE, have C/RE create them
      • If they *do* previously exist in RE, link to them. This will update the RE rec with fresh information
    Does this make sense to folks?

    I'm interested in any feedback as I'm about to pitch it to my administration....

    -john
  • Nancy Cunningham
    Nancy Cunningham
    Ninth Anniversary Participant Facilitator 1
    I'm very interested in feedback on this topic and will be following.
  • David Gillespie
    David Gillespie
    Tenth Anniversary Kudos 2 Name Dropper Participant
    John,


    Our approach is a bit different, which branches from your one statement: "Isn't the whole "system" designed toward keeping current student [and parent] data in Core and keeping [and using] alumni information in RE/Nxt?" For us, it's not. Education Management / Core holds all our faculty/staff, students, parents, alumni, and parents of alumni for those who graduated since 2007 (our conversion year). As a result, we use pushpages to communicate with our constituents. A while back it was harder to load others like grandparents and friends, but with the relatively recent import improvements, that's a breeze. For workflow, we don't use Connect RE. A development office staff member uses the "Handle Profile Changes" function in Core to determine what she needs to update in Raiser's and those updates are all manual so she can watch for bad data and undo anything that shouldn't be done (we allow high school students to edit a limited amount of their info, for example). We are a school of 1400 students and she doesn't seem to have issues keeping up with those updates. When she receives updates directly to her office, she makes them in HawkNet (EM) also. We use the Raiser's Edge "import ID" as the "Host ID" in EM which ties the records together for import/export. The relationship linking isn't identical since everyone is an individual in EM and we use the "primary/spouse" layout in RE and when people switch positions (e.g. an existing spouse becomes an employee and switches to "primary"), things have to be massaged more carefully. The system appears to work well, and doing an every-so-often complete refresh of EM from RE (via import) keeps things clean. You could do that refresh weekly if you wanted to, particularly if you have a tool to convert RE exports into EM imports so it's not so painful.


    Anyway, that's our take. We don't totally love pushpages; we wish they were responsive (at least) and we wish we could upload any list of email addresses / constituent IDs, rather than build a list based on conditions. But it works well for most of our applications, particularly the subscription lists, status reporting, and pushpage archive, so we haven't switched to another method yet. And we don't have another substitute for alumni online access (we've tried several - that's a whole separate thread!) so EM is also their way to access the school calendar, directory, and SSO into the photo server and other tools. So we need them in there.


    Dave
  • Susan Ross
    Susan Ross
    Fifth Anniversary Kudos 1 Name Dropper Facilitator 1
    We have ALL teachers, non-teaching staff, coaches, students, parents, grandparents, alum, alum parents and some alum grandparents, past students, past parents in CORE and all of the constitutes in RE NXT. We imported alum and alum parents for the Class of xxxx from RE NXT that were not in EE when we converted from EE to ON. We use the Connect RE interface. All demographic information is updated in CORE and flows to RE NXT. We do not have a problem with duplicate records (you can set the flag during import to add only if not existing). We send PushPages through CORE to parents, grandparents, alum, and alum parents. A Custom Field can be set up for Solicitation Codes and used for distribution lists, extracts, reporting, etc. Having all of the constitutes in one database has been a benefit for our Admissions (we only accept online applications) and Development teams. We use a Custom Field to identify Legacies (much easier to quickly identify a Legacy than looking at Relationship records.) We still need to import our past students and past parents (and possibly past grandparents - have not decided) into the ON product for the years prior to our conversion. This has not been a big problem, but it's on the list of projects because we do have past students and past parents that submit applications and become students (again) and parents (again) or a past student becomes a parent, etc. There has been a few past grandparents that we imported because they became current grandparents again (not many, but we do not want to loose the relationship information). Right now, we add these past student and past parent records individually (through an import) but do plan to add all of them in ON at some point. For our PushPages, we mostly use a banner heading and a footing banner (color) with text in the middle. This process works smoothly for us! We are currently expanding our use of these features...having alum and alum parent records in the ON product will allow our Development team to post to the Alum Resource Board information such as our annual alum and alum parent Crawfish Boil, etc., allow for profile information to be updated easily, and for alum and alum parent directories (which we have a filter by Class of xxxx) also. We are still trying to figure out what directories we need / would be helpful and who should have access to them. We have a Board of Trustee directory. It took a several months to get our data imported and cleaned up, but it's working for us and and we continue to expand and build to meet our ever growing data needs.
  • Susan Ross
    Susan Ross
    Fifth Anniversary Kudos 1 Name Dropper Facilitator 1
    Setting up a Custom Field within CORE for solicitation codes might help you....can create advanced distribution lists for PushPages and other reporting using Custom Fields. If this won't work, I'm curious as to why not -- hoping down the road we don't have a problem that I don't see forthcoming.

Categories