What's new (service pack 36)

TheBlackbaud CRM Luminate Online Connector now enables organizations to choose to sync premium benefits which are associated with Luminate Online transactions to Blackbaud CRM transactions as benefits. Find this new option in Global Settings. To use it, run the Premium Log sync after you sync revenue but before query imports.

We've also added additional fields to the query view of the Luminate Sync Log. These include:

• LO_QUERY_ID,

• CONSID,

• TREVENTID,

• TRREGISTRATIONID,

• TEAMID,

• CEEVENTID,

• CERSVPID,

• and INTERESTID.

This query's name and record type also no longer show an indicator that says (Custom).

You can use another new Global Setting called Update acknowledgee constituent info to update existing constituent records for matched tribute acknowledgees with any new name, address, email, or phone info in batch. By default, this option is set to Do not update, which maintains the previous behavior and thus doesn't add any new info to the matched acknowledgee.

This update increases consistency between Research Point, Altru, and Blackbaud CRM.

When a user attempted to use an advanced search to find new prospects, the options for minimum and maximum Confirmed Wealth in CRM differed from the options for similar searches in Research Point and Altru.

This is fixed; now the value ranges for CRM are the same as those in other Blackbaud solutions. This also increases the maximum to $50,000,0001, instead of $10,000,001.

This addresses an issue with Global Change Processes. Previously, the permissions for business processes were based off of the Business Process Owner.

A new task called Run global changes as the executing user is now available in Global Changes. Enable it to have all Global Changes manually run by a user to run under that user's permissions.

Once enabled, you can select Run global changes as the process owner user to revert back to using the business process owner's permissions.

Previously, if a user selected the option to Update only addresses with forwardable moves or Update only NCOA changes, then all addresses were downloaded.

Now, you can significantly reduce the number of records the process handles and thus improve performance.

For details, refer to the Blackbaud KnowledgeBase (article 203720) .

Note: If a user selects Update all addresses, then the process remains unchanged and is not optimized.

Blackbaud Internet Solutions doesn't interrupt you upon server session timeout. This enables you to complete complex or time intensive tasks. You'll still be logged out due to inactivity, however you won't be automatically redirected to the login page. Thus, you'll still appear to be logged into Blackbaud Internet Solutions until you refresh the browser session.

For security purposes, we therefore recommend you:

• check your internet browser settings to ensure your cookies and cache will be automatically cleared whenever you exit the browser.

• manually log out of Blackbaud Internet Solutions whenever you complete your tasks.

• do not remain logged in with an open and active browser session when you are away from your device.

With service pack 36, we've upgraded the jQuery user interface (UI) from version 1.13.0. to 1.13.2 for Internet Solutions (BBIS).

Service pack 36 includes phase 1 of an update that gives your organization more control and flexibility over how you track the gender of constituents.

Previously, you could only indicate that the constituent's gender was one of four hard-coded options (Female, Male, Other, or Unknown).

If you want to configure additional options, you can now do so by adding them to the new Gender code table. The new Code Table has been pre-populated with copies of the four hard-coded gender values. Find the new Biographical Code Table in the Administration functional area.

The original, hard-coded gender field (GENDERCODE) currently remains "under the hood" with its four hard-coded values. This ensures backwards compatibility for customizations and integrations with other Blackbaud, partner, and in-house applications. You will need to update your customizations and some integrations to refer to the new code table (GENDERCODEID) to complete the transition.

• Add and Edit forms will now display the new code table field Gender in place of the old field.

• One-Way Trigger Sync. When the new GENDERCODEID field is changed, then the old GENDERCODE field will be changed to be in sync with the new field.

• Duplicate Search and Merge

• Gender defaulting behavior for First Names and Title Codes

The hard-coded Gender field (GENDERCODE) has been replaced by the new Gender field (GENDERCODEID) in query views and exports based on:

• V_QUERY_CONSTITUENT

• V_QUERY_CONSTITUENTMARKETING

• V_QUERY_RECORD

• V_QUERY_HOUSEHOLDCONSTITUENT

• Constituent Update Batch (CUB)

• Revenue Update Batch (RUB)

• Enhanced Revenue Batch (ERB)

• Membership Dues Batch (MDB)

• Constituent Update Batch

• Enhanced Revenue Batch

• Membership Dues Batch

• Constituent - set GENDERCODEID based on GENDERCODE

• Batch - set GENDERCODEID based on GENDERCODE in uncommitted batches

• Set all first names to Any gender (on First Names page)

• Acquisition form

  • Merge field for acknowledgment email

  • Additional fields

• Chapter page element

  • Directory (including the search form and listing field)

• Directory (including the search form and listing field)

• Profile display

• Profile update form

• User login

  • Merge field for new user registration email template

  • Merge field for forgotten password/username email template

  • Additional fields

The new gender code table is pre-populated to include copies of the 4 original values (female, male, other, unknown). Like other Code Tables, your organization can also:

• add additional values,

• edit a description,

• change the sort order,

• mark a value (in)active,

• edit permissions,

• and delete any values your organization added (if they are no longer used on any records).

  Note: Due to backwards compatibility with integrations, customizations, and other solutions, you can't delete the 4 original values from the new code table (GENDERCODEID). But if you no longer use them, you can mark them inactive.

The original, hard-coded, gender field (GENDERCODE) will only populate the new user-defined field (GENDERCODEID) one time as part of the service pack deployment for most organizations.

Any future data entered into the hard-coded gender field (GENDERCODE) will not automatically sync to the new GENDERCODEID field. If you continue to enter data in the legacy gender field (GENDERCODE), then you must run a Global change business process to ensure the new user-defined gender field (GENDERCODEID) is also populated.

However, when you enter data into the new user-defined gender field (GENDERCODEID), the value of the constituent's hard-coded field (GENDERCODE) will automatically sync to a corresponding value.

When you add or update the new user-defined code table (GENDERCODEID) to:

• Female, then the hard-coded GENDERCODE will be Female.

• Male, then the hard-coded GENDERCODE will be Male.

• Other, then the hard-coded GENDERCODE will be Other.

• Any new value created by your organization, then the hard-coded GENDERCODE will be Other.

• Unknown, then the hard-coded GENDERCODE will be Unknown.

• Blank (Null), then the hard-coded GENDERCODE will be Unknown.

Tip: If your constituent table is exceptionally large, deploying service pack 36 may take more time than previous service packs. These organizations may want to choose an alternative deployment to reduce downtime. Review Blackbaud KnowledgeBase (article 203650) for full details.

Before you upgrade to service pack 36, examine all customizations and API integrations to audit whether they use the hard-coded GENDERCODE field.

As soon as possible, ensure they're updated to use the new GENDERCODEID code table after service pack 36 is deployed. This will enable you to capture new and updated gender data.

We recommend you start with:

• Individual.Add.xml

• IndividualRecord.Add.xml

• IndividualOnlyRecord.Add.xml

• IndividualRecordSimplified.Add.xml

• IndividualSpouseBusinessSpouseForm.xml

• Household.Add.xml

• HouseholdMember.Add.xml

but remember to check every place you reference gender.

Note: The old hard-coded GENDERCODE field still remains "under the hood" on forms. Only the new GENDERCODEID code table appears in the user interface.

Service pack 36 updates how the gender field is automatically populated based on first name. (See first name and gender defaults.)

Previously options that a first name could be configured to default to were Female, Male, and Unknown. They are now Female, Male, and Any.

When you use First name to automatically default a Gender value, the Female and Male values only support the new Gender (GENDERCODEID).

When a First name is:

• Female, the GENDERCODEID field is set to Female when a user enters the name.

• Male, the GENDERCODEID field is set to Male when a user enters the name.

• Any, the GENDERCODEID field is not set to any value when a user enters a name .

Thus, the default functionality has been preserved and organizations do not need to take any action to continue using first names to automatically populate gender for constituents.

Tip: Since Blackbaud CRM includes over 5,000 first names automatically configured for gender defaults, this new Task ensure you don't need to manually reconfigure each name's gender default.

To permanently stop defaulting gender based on First name:

1. From Constituents, select First names under Configuration.

2. Under Tasks (left panel), select Set all first names to "any" gender".

This configures all first names to default to Any gender. This can't be undone. Users must have a feature permission set via their System Role to enable them to make this permanent change.

Service pack 36 updates how the gender field is automatically populated based on title code. (See Title codes and gender defaults.)

Previously options that a title code could be configured to default to were Female, Male, and Unknown. They are now Female, Male, and Any.

When you useTitle codes to automatically default a Gender value, the Female and Male values only support the new Gender (GENDERCODEID).

When a Title code is:

• Female, the GENDERCODEID field is set to Female when a user enters the title code.

• Male , the GENDERCODEID field is set to Malewhen a user enters the title code.

• Any, the GENDERCODEID field is not set to any value when a user enters a title code.

Thus, the default functionality has been preserved and organizations do not need to take any action to continue using title codes to automatically populate gender for constituents.

Tip: A future service pack will include a new Task that enables organizations to "turn off" gender defaults for Title codes. Similar to theTask for First name, it'll permanently set all Title codes to default to Any gender.

Ideally, you should commit all batches before deploying service pack 36 (or any service pack).

However, if you have uncommitted batches after the deployment, you can run a global change business process to map the "draft" values for the hard-coded GENDERCODE field to the new GENDERCODEID field before you commit the batch.

1. Select Administration.

2. Select Global changes.

3. Select Set new gender values based on old values in uncommitted batches.

4. For Parameters, choose Selected batches.

5. Select your uncommitted batches. Use batches with these templates:

   • Constituent Update Batch (CUB)

   • Enhanced Revenue Batch (ERB)

   • Membership Dues Batch (MDB)

6. Select Save.

7. Select Start process to run the global change immediately or Create job schedule to run it at a later time.

When the process runs on the selected batches, the new GENDERCODEID column in the uncommitted batch is updated based on the hard-coded GENDERCODE value.

• Female to Female.

• Male to Male.

• Other to Other.

• Unknown to Unknown.

Want to verify the results after the global change is processed? Customize the batch fields to show the new GENDERCODEID with its values.

Tip: Please review the Risks of uncommitted batches .

Run this global change business process to sync gender values.

For example, consider using this if an old customization or a batch only included info for the hard-coded GENDERCODE value.

To begin, you'll need a selection of constituents, such as new constituents from a batch.

Tip: You'll also use this process if you have an exceptionally large database and chose to use the alternative deployment process for service pack 36.

For details, see Data Query Selections. Then use the selection to run the global change:

1. Select Administration.

2. Select Global changes.

3. Select Set new gender value based on old value

4. For Parameters, choose Constituent selection.

5. Choose your selection of new constituents.

6. Select Save.

7. Select Start process to run the global change immediately or Create job schedule to run it at a later time.

When you process the global change for your selected constituents, it'll update the new GENDERCODEIDcolumn in the constituent record based on the current hard-coded GENDERCODE column value saved for the constituent record.

• Female to Female.

• Male to Male.

• Other to Other.

• Unknown to Unknown.

If you are using a user defined constituent attribute, of a code table type, that has been named "Gender," then you'll need to rename it before you upgrade to Service Pack 36. This is due to a naming conflict that can cause the upgrade to fail on a service revision indicating "Code table name 'Gender' already exists".

Please contact Blackbaud customer support to receive a script fix prior to running the upgrade, if you have implemented a constituent attribute to store gender data.

If your constituent table is exceptionally large, deploying service pack 36 may take more time than previous service packs.

Use your test environment to help predict whether deploying this service pack might cause your organization's downtime to be "too long."

If you are unable to schedule an upgrade that handles that much downtime, there is an alternative to consider.

Instead of allowing the upgrade to automatically populate every constituent record with a new gender value based on the old value, you can force the upgrade to not populate the new gender field for each constituent. Instead, you'll run business processes after the deployment to populate the new gender field for constituents.

Review Blackbaud KnowledgeBase (article 203650) for full details.

When you search for potential duplicate constituent records and merge them together, the processes now use the new Gender field ( GENDERCODEID).

When you merge records the gender of the Source remains unchanged.

The target's resulting gender is determined as follows:

• if both the Source and the Target have known gender values (such as Female, Male, Other, or any new user-defined value), then the Target retains its gender value as the result. For example,

  • If Source is Male but Target is Female, then the Target result will be Female.

  • If Source is Female and Target is Female, then the Target result will be Female.

  • If Source is Female and Target is a new user-defined value, then the Target result will be the new user-defined value.

  • If Source is a new user-defined value and Target is Female, then the Target result will be Female.

• if either the Source or the Target had Unknown or Blank (Null) gender, but the other has a known gender, then the Target's gender result will be the known gender. For example:

  • If Source is Male but Target is Blank (Null), then the Target result will be Male.

  • If Source is Blank (Null) but Target is Male, then the Target result will be Male.

  • If Source is a new user-defined value but Target is Blank (Null), then the Target result will be the new user-defined value.

  • If Source is Blank (Null) but Target is a new user-defined value, then the Target result will be the new user-defined value.

• if either the Source or the Target had Unknown or Blank (Null) gender, and the other is also Unknown, then the Target's gender result will be Unknown. For example:

  • If Source is Blank (Null) and Target is Unknown, then the Target result will be Unknown.

  • If Source is Unknown) and Target is Blank (Null), then the Target result will be Unknown.

• if both the Source and the Target had Blank (Null) gender, then the Target's gender result will also be Blank (Null).

When you create a new query, the new Gender field is used to filter and to show constituent data. It therefor includes user-defined values from your code table - GENDERCODEID.

When you view a query you created before service pack 36, it continues to show Gender data based on the older, hard-coded field (GENDERCODE) instead. It only filters based on the four hard-coded values.

We recommend you update your existing queries to use the new field. To do so, you'll manually "swap" the Gender field used by the query.

1. Remove the existing Gender field (the hard-coded GENDERCODE).

2. Re-add the Gender field (the new code table field GENDERCODEID ).

   Note: Although the old and new versions use the same name in the user interface, this "swap" ensures the query is updated new version with your organization's user-defined options.

3. Remove the old Gender field filter.

4. Re-select the Gender field from the Fields list and re-add it as a Filter.

5. Remove the old Gender field from the display fields.

6. Re-select the Gender field from the Fields list and re-add it to Display fields.

7. Remove the old Gender field from sorting.

8. Re-select the Gender field to Sort new field.

Repeat this process for all existing Selections and Smart Queries to update the Ad-hoc queries.

Tip: Before you upgrade to service pack 36 (or any service pack) we strongly recommend you commit all uncommitted batches (especially any that were created from imports).

With this update, all new batches use the new Gender field (GENDERCODEID), including new batch templates and new uncommitted batches.

Four existing import templates also use the new Gender field:

• Constituent Update Batch (CUB),

• Revenue Update Batch (RUB),

• Enhanced Revenue Batch (ERB),

• and Membership Dues Batch (MDB).

Other existing batches and templates continue to use the older, hard-coded Genderfield (GENDERCODE). We recommend you edit them to use the new field instead. Then use the updated templates when you commit batches after deploying service pack 36.

Warning: New uncommitted batches created as the result of old legacy imports, where the old import still use the hard-coded Gender field (GENDERCODE) are handled as existing batches. You'll need to edit them to use the new code table version instead.

When you edit a batch template that was created before the upgrade and the batch template previously had the Gender field selected, you'll notice that the field will no longer appears under Selected fields. This is because the hard-coded field (GENDERCODE) was selected. Re-add the Gender field under Selected fields. This will be the new code table Gender field (GENDERCODEID ) instead.

Not sure whether your batch template is using the new Gender field versus the old Gender field? Create a new batch using the template and then review the options available in the Gender field's drop down menu. If you see:

• Blank (Null) and any of the user-defined options your organization added to the code table, then it is updated to use the new field.

  You'll also see options for Female, Male, Other, and Unknown.

• only 4 options (Female, Male, Other, and Unknown), then your batch template has not been updated.

  You can use a global change process to update the new Gender value based on the old Gender value in your uncommitted batch or in the constituent record after you’ve committed the batch.

Before you upgrade to service pack 36 (or any service pack), we strongly recommend you commit all uncommitted batches (especially any that were created from imports).

However, if you created a uncommitted batch before deploying service pack 36 and need to commit it after the upgrade, use the workarounds provided in this help topic to ensure the "draft" values for the old Gender field properly sync to the new Gender field.

Failure to do so will result in the new Gender field (GENDERCODEID) committing as Blank (null) even if the old Gender field (GENDERCODE) had a value. Why?

• For existing constituent records, this triggers a data sync due to a change in the new Gender field.

  If the new Gender field's initial data was automatically populated by the deployment of the service pack, based on the old Gender field, this value is overwritten by the commit.

  Then the ongoing data sync updates the old Gender field to Unknown.

• For new constituent records, the new Gender field defaults to Blank (null) and thus the ongoing data sync doesn't detect a change in this value.

  The older Gender field is updated to the values in the batch. Thus, although this data isn't lost, you'll need to run a Constituent global change to populate the new Gender field.

If you still need to handle uncommitted batches after deploying service pack 36, use a workaround.

Constituent Update Batches (CUB) created before the upgrade retain "draft" gender values for the hard-coded Gender field. You can view these values in the batch.

To manually set values for the new Gender field, export the uncommitted batch.

Then re-import the data using a batch template that includes the new Gender field.

Warning: Don't customize fields on uncommitted constituent update batches after upgrading to service pack 36. When you edit these uncommitted batches, you'll notice the old, hard-coded Gender field and "draft" values. If you customize the fields, then you'll also notice that Gender is not a Selected field. If you then add the Gender field to the batch columns, it adds the new Gender field and replaces the old one. Since the new Gender field doesn't have any "draft" values saved to it yet, the new values will all appear as Blank (null). Meanwhile the old Gender field will no longer be visible nor available to export from the batch via the front end. However, values for the old Gender filed (GENDERCODE) and the new Gender field remain in the "back end."

This workaround doesn't apply to Enhanced Revenue Batch (ERB), Membership Dues Batch (MDB), and Revenue Update Batch (RUB). Curious why?

• Enhanced Revenue Batch and Membership Dues Batch - When you edit the constituent’s gender from the uncommitted batch, it's saved as a "draft" update to the constituent, but in separate table in the batch. It doesn't update the constituent record directly until after the batch is committed. These constituent edits are also saved in an XML collection in the batch rather than as batch columns. Thus, you can't export the batch grid, since this won't export the values in the constituent XML collection fields.

  Instead, use workaround option B to handle Enhanced Revenue Batches and Membership Dues Batches which were created before the upgrade and but remain uncommitted after the upgrade.

  In these uncommitted batches, the "draft" values for the old Gender field are still captured in the batch tables. If you edit the uncommitted batch after the upgrade from the front end, you'll see the old Gendervalues are retained. Similarly, the values appear in the "back end."

• Revenue Update Batch - When you edit the constituent’s gender from the uncommitted batch, the update is directly saved to the constituent record. Thus, there aren't any "draft" values for the old Gender field.

  When you deploy service pack 36 (or apply the necessary global changes as a very large database), the constituent's gender is synced from the old Gender field to the new one. Thus, when you edit a constituent from Revenue Update Batch, it shows the updated new Gender field value correctly.

  Likewise, if you edit the constituent from the uncommitted batch, it saves your update directly to the constituent record and the new Gender field.

Constituent Update Batch (CUB)

• Uncommitted batches which were created before the upgrade retain "draft" gender values for the old Gender field. You can view these values in the batch.

• Use a global change to set the values for the new Gender field based on the values in old, hard-coded Gender field in the uncommitted batch. See Set new gender values based on old values in uncommitted batches.

Enhanced Revenue Batch and Memberships Dues Batch

• When you edit the constituent’s gender from the uncommitted batch, it's saved as a "draft" update to the constituent, but in separate table in the batch which doesn't update the constituent record directly until after the batch is committed.

• Use a global change to set the values for the new Gender field based on the values in old, hard-coded Gender field in the uncommitted batch. See Set new gender values based on old values in uncommitted batches.

This workaround doesn't apply for Revenue Update Batch (RUB). Curious why?

• When you edit the constituent’s gender from the uncommitted batch, the update is directly saved to the constituent record. Thus, there aren't any "draft" values for the old Gender field.

  When you deploy service pack 36 (or apply the necessary global changes as a very large database), the constituent's gender is synced from the old Gender field to the new one. Thus, when you edit a constituent from Revenue Update Batch, it shows the updated new Gender field value correctly.

  Likewise, if you edit the constituent from the uncommitted batch, it saves your update directly to the constituent record and the new Gender field.

After you deploy service pack 36, all new imports will use the new code table for the Gender field, including new batch templates and new uncommitted batches.

Blackbaud has updated the following import templates to include the new Gender field.

• Constituent Update Batch (CUB)

• Enhanced Revenue Batch (ERB)

• Membership Dues Batch (MDB)

However, if your organization created additional imports and templates based on those three, then you'll need to update your versions.

Existing imports and templates created before the upgrade will still use the old Gender field. Update them to use the new Gender field (GENDERCODEID) instead.

Re-map the gender fields, including Constituent gender and Spouse gender, in the file mapping template.

Note: If the file mapping template was created before upgrading to service pack 36, the Spouse gender field won't appear in the Batch Template Columns list. This is a known issue. Recreate the file mapping template as a new one and delete the old one. This issue only appears in CUB; it doesn't occur in ERB or MDB.

Tip: We strongly recommend you review, then remap and/or recreate all actively used file mapping templates as soon as possible after the upgrade. We also strongly recommend you commit all uncommitted batches that were created from imports. If not, you'll need to follow a workaround to handle the uncommitted batches.

Note: If you run an import process using an old batch template that doesn't use the new Gender field (GENDERCODEID ), then the import will only update the old Gender field (GENDERCODE ). If the import then generates an uncommitted batch, the batch will likewise behave like it's "older" (as if it were created before upgrading to service pack 36). You'll need to follow a workaround to handle the uncommitted batches.

The new code table for user-defined gender will be added to more areas in a future service pack, such as:

• Blackbaud Data Warehouse

• Gender defaulting behavior (set all title codes to Any gender)

• Marketing & communications

• Relationship type settings (support new field and set all relationship types to Any gender)

• Reporting

• Sponsorships

  Gender data for Sponsorship child records are stored in a different data table and these records are not constituent records in Blackbaud CRM.

  Thus, the user-defined gender code table described for service pack 36 doesn't impact sponsorship child records. Those records and their functionality currently remains unchanged, with gender options of:

  • Female,

  • Male,

  • and Unknown,

• WealthPoint

  Biographical data (including gender) which is stored in WealthPoint is not linked to constituent records in Blackbaud CRM. The data is handled by ResearchPoint and thus the user-defined gender code table described for service pack 36 doesn't currently impact biographical data (including gender) stored in WealthPoint.

• Data enrichment services

  The following subscription services remain unchanged and are not affected by the new gender field added in service pack 36.

  • AddressAccelerator

  • AddressFinder

  • DeceasedRecordFinder

  • EmailFinder

  • GenderFinder

    Note: When this provides a gender, the data is currently saved to Blackbaud CRM as a Attribute on the constituent's record. It is not saved to the to the new GENDERCODEID or legacy GENDERCODE field. For details, see the How to process GenderFinder in CRM article in the Blackbaud Knowledgebase.

  • PhoneFinder