Service pack 32

To improve readability, default sort has been added to the Customize Home Page to display the Task lists in alphabetical order.

To improve efficiency, users can now copy existing User-defined Data Lists from Shell Design.

A new Paste list button has been added that allows users to paste lists (such as IDs, ZIP Codes, etc. from an Excel column) into the Ad Hoc QueryOne Of and Not One Of filter criteria. The paste list button is only available for text and number fields. The button provides a free text area where users can paste a copied list of values, then add the values as rows to the grid based on line breaks as the delimiter.

Note: In ad-hoc query there is an existing limit of 255 filter values, and a value can't be longer than 100 characters. Please be mindful of these limits when you are pasting longer lists or values into the Copy/Paste List text area. Currently, the text area itself does not have any of these value or character limits. The system will warn you of the 255-value limit when you try to preview the results or save the query, and it will warn you of the 100-character limit per value when you try to apply the criteria. If you have more than 255 filter values that you would like to include in the criteria, then you can add multiple filters with the combining operators. Explicitly including a large number of values (many thousands of values) using the One Of and Not One Of filter operators could slow down your query or cause an error.

Blackbaud Internet Solutions (BBIS) now provides the option to configure Personal Information collection on the Mini Donation Form. When enabled, the donor sees the available fields on the Personal Information tab of the form.

To enable collection of personal information from the user, select the enable check box Collect personal and biographical information from the donor.

Note: By default, this checkbox will be unchecked.

Language Tab

The Language tab has newly available fields to allow field label preferences and data entry validation.

Confirmation Screen

The Confirmation Screen Merge Fields take account of the newly available fields to allow a more personalized confirmation display.

Revenue Attributes

The enabled Mini Donation Form can collect Revenue Attributes.

The revenue attributes that appear in this frame are created in Blackbaud CRM. After you process a donation transaction, the attributes you select appear on the Attributes tab of a revenue record.

From the Attribute popup, select the checkbox beside the gift attribute to associate with the part. To make the attributes required, select the checkbox in the Required column. To change the text of the attribute on the donation page, enter the text to display in the Label field.

Note: You can use one-per-record attributes with types of Date, Text, Number, Currency, and Yes/No in the program. Table type attributes are available without being marked as one per record. Fuzzy Date, Constituent Name, Memo, and Time type attributes are not available.

With this Service Pack, Blackbaud Internet Solutions (BBIS) reCAPTCHA appears on pages when users choose the Bill Me Later option during a transaction.

The Following pages and parts are affected by this change:

Pages configured with Payment 2.0:

• Donation Classic

• Sponsorship Status

• eCard with Donation

Pages without Payment 2.0:

• Event 2.0

• Donation Classic

• eCard with Donation

• Sponsorship Status

• Personal Page Manager

With this release of Blackbaud Internet Solutions (BBIS) , phase III of the password reset functionality is now available. The new updates are as follows:

• The RecordNewUserHandler custom handler no longer accepts password fields. New users are now created using RecordNewUserHandler without passwords.

• The application can send a new user welcome email with a password reset link while creating the user via RecordNewUserHandler or not, depending on the organization’s preference.

• New user signup emails are sent based on the new parameter flag SkipNewUserWelcomeEmail.

  • By default, its value is false so that current clients using this customer handler don’t need to make any changes and can continue to send Signup emails along with new users.

  • If you don’t want to send welcome emails, update this parameter flag to true.

Users can now reset their password via the following methods when the SkipNewUserWelcomeEmail parameter flag value is set to true:

• By clicking the Forgotten password link from the login part/login.aspx page.

• By requesting the organization send the password reset email.

For more information, view page 12 of the Single Sign-on Overview Guide to learn about the RecordNewUserHandler custom handler field table.

With this release, Blackbaud Internet Solutions (BBIS) moved all CMS Business Processes to run on SQL Jobs.

Impacted CMS Business Processes are:

1. Jobs available under the Schedules tab of Sites and Settings section (except Email related business processes, as they are already running through SQL Jobs)

2. Jobs running in the background (CMS Checkout Repair, Blackbaud Secure Payments Transaction Repair etc.)

With this release of Blackbaud Internet Solutions (BBIS), reCAPTCHA now displays for free event registrations. This implementation is for Event 2.0 and Event Classic (except Payment 2.0).

With this release ofBlackbaud Internet Solutions (BBIS), Donation Forms now has its own New User Signup email template that can be used to send a New User Welcome email when users sign up from the Donation Classic page.

A new tab has been created for the welcome email template i.e., New User Registrationemail in Donation Form part.

With this release of Blackbaud Internet Solutions, the LinkedIn Group Join part (4.0 & 5.0) has been deprecated due to changes in LinkedIn's API. No new instances of this part type can be created. Existing pages will show a yellow banner indicating the part has been deprecated but existing transaction data will be retained.

The LinkedIn setting has been removed from the API tab under Sites and Settings.

Previously, SQL Server Reporting Services (SSRS) worked with Windows Authentication by default and was accessible through Windows credentials.

Historically, established Active Directory (AD) organizational units were added and managed via the Blackbaud CRMOrganizational Units area. However, with Blackbaud CRM moving to a Blackbaud ID SSO (single sign-on) approach, this functionality as well as the ability to add domain users in Blackbaud CRM and login through to SSRS will be unavailable.

As a result, SSRS has been modified to use Blackbaud ID credentials in line with Blackbaud CRM.

Existing users, subscriptions, and custom reports will be automatically migrated to Blackbaud ID SSRS by Blackbaud with the appropriate roles.

Request Blackbaud ID authentication for SSRS

1. Ensure that you are on the latest Service Pack and hot fix.

2. You must already have Blackbaud ID enabled in the environment(s).

3. File a ticket with Blackbaud Support to enable Blackbaud ID authentication for SSRS.

4. Provide the following information to support:

   1. Name and contact info.

   2. The Blackbaud ID email address of any SSRS Subscription owners. If you do not know this information, we can provide a list of existing Subscription owners to assist with this.

   3. Blackbaud CRM Environment(s) to be enabled (Staging, Test, Production).

   4. Preferred date and time.

   Note: When using SSRS with Blackbaud ID in non-production environments, it is strongly recommended to upgrade all environments rather than a subset. If you choose to upgrade some environments but not others, the report servers that are not upgraded will not function properly. If all environments are upgraded, then reports on all of them will function properly and be secured by Blackbaud ID.

   Upgrading non-production environments will not affect production environments. Blackbaud ID can be enabled on report servers in production environments separately and, optionally, at a later date. You can choose to enable Blackbaud IDAuthentication for SSRS in a lower environment first, before moving to Production.

5. Our support team will contact you to confirm and arrange a time to perform the enablement. The enablement tasks don’t take long, and a support representative will advise you when these are completed.

6. Blackbaud Hosting will enable Blackbaud IDAuthenticated SSRS.

New Blackbaud CRM Roles for SSRS

As Blackbaud ID SSRS users are tightly coupled with Blackbaud CRM Application Users, SSRS roles have been introduced within Blackbaud CRM for handling the required permissions.

Managing these roles and permissions is undertaken via Blackbaud CRMApplication Security. When there is a login to SSRS, it is reflected automatically. Any role or Application User changes in Blackbaud CRM are immediately manifested into SSRS.

There are five types of roles that can log in and be authorized in SSRS which have corresponding roles available in Blackbaud CRM.

These Blackbaud CRM Roles are:

1. ReportAdmins - has Browser, Content Manager, My Reports, Publisher, Report Builder rights.

2. ReportContentManagers - has Browser, Content Manager, Publisher rights.

3. ReportBuilders - has Report Builder rights only.

4. Report Publishers – has Publisher rights only.

5. ReportBrowsers - has Browser rights only.

These are added to application users via the existing Blackbaud CRM system roles workflow. Refer to the Blackbaud CRMSecurity Guide.

Note: If your organization does not use SSRS, these new roles can safely be ignored.

How is SSRS accessed after the Blackbaud ID upgrade?

After the upgrade of SSRS to Blackbaud ID, when a user accesses a URL for SSRS they are redirected to the signin.blackbaud.com page where they need to enter a valid Blackbaud ID username and password. This Blackbaud ID user should be mapped to the Blackbaud CRM application which has the SSRS instance associated.

After the Blackbaud ID login is validated, the user is redirected to the available environments screen (where they can see only those environments to which they have access), in order to choose the environment for which they want to see the reports.

After selecting the environment from the available environments dropdown list, users should select the Go to Browse button to open the SQL Server Reporting Services folder.

Now users can access reports based on their permission roles in the SSRS.

To provide additional security and easier permission management for automated logins, such as for integrations, you can now create proxy users. A proxy user or NIU (non-interactive user) is a copy of an application user that inherits the application user's system roles and permissions but authenticates with a PAT (Personal Access Token).

Note: Only application users with appropriate system permissions can create proxy users and assign personal access tokens.

Note: BBJobUser, Report User that handles communication on the SQL side between Blackbaud CRM and Reporting services, BBNCAppPoolUser and OLAP user remain as Windows users.

The Application User Page has two additional columns, Is proxy and Proxy user owner which are available whether Blackbaud ID is on or off.  Neither of the columns are displayed by default but can be selected for inclusion in the Application Users data list via the Columns selector.

Note: The above image shows an environment with Blackbaud ID turned off.  When Blackbaud ID is turned on the columns are added and display in the same way.

You can add and maintain proxy users via the existing Application Users page.

Blackbaud CRM users with the necessary permissions can add, edit, and delete proxy users, as well as manage personal access tokens.

Unique proxy user names can be viewed in the Application User data list as the Login name (relabeled as Domain name in a Blackbaud ID environment) and is the same as their unique username which is used for authentication. When a third-party software authenticates with Blackbaud CRM, Altru or ResearchPoint, it uses the proxy user display name along with the PAT and the Blackbaud CRM, Altru or ResearchPoint client database.

Proxy users are non-interactive and don't have email addresses.

The Application User Page has a new tab labeled Proxy Users that is only visible for application users who are proxy owners. This tab lists the proxy users belonging to that proxy owner. The proxy users are hyperlinked and you can access their Application User Page by clicking on their name.

The Application User Page has a Personal Access Token tab that is only visible for application users who are also proxy users and a Summary section indicating their proxy owner.

The Application User Search feature has a filter to allow searching for proxy users.

Proxy users are marked inactive after five consecutive failed attempts to authenticate. If a proxy user is marked active, they can attempt to authenticate.

Proxy users can be created in the system by converting existing application users.  On the Application User Page, new tasks are available for a candidate application user.

The display name is based on the AD (Active Directory) username related to the unique AD name. e.g., Blackbaud\Bob.Smith would still have the display name Blackbaud\Bob.Smith after conversion. The application user attempting the conversion is the proxy owner of the proxy user.

Only certain application users can be converted to proxy users and in the cases below the Convert to Proxy User task isn't visible.

• System, BBJobUser, Blackbaud ID application users and application users who have system administrator privileges can't be converted to proxy users.

• An application user who is already a proxy user can't be converted.

• An application user can't convert themselves to be a proxy user (they can't be their own proxy owner).

• An application user who is already a proxy owner can't be converted.

Conversion to a proxy user is a one-way process.  If an application user is accidentally converted to a proxy user it isn't possible to convert them back to an AD user or Blackbaud ID user.  There is a warning message displayed before conversion.

If an AD application user is converted to a proxy user it's possible to add the AD application user again, but the same AD user can't be converted to be a proxy user a second time.

When converting an application user to a proxy user, the system roles are maintained. The proxy owner needs to have the same or more permissions than their proxy user.  If the proxy owner to be (i.e., the application user doing the conversion) doesn't have sufficient system roles (not having the system roles themselves or not a system administrator) then an error message is shown, and the application user isn't converted to a proxy user.

When conversion is successful the application user becomes the proxy owner of the newly converted proxy user. The proxy user then has their pre-existing email address removed.

Inside of the Blackbaud ID Environment

• Application users with access to the Application User Page, proxy owners and proxy users can be marked inactive.

• Once marked inactive, users can’t login successfully until they are marked active again. When a proxy user is marked inactive, all their PATs are revoked. If a proxy user is marked active again, the proxy owner has to add a new PAT for their proxy user before they can successfully log in.

• When a proxy owner is marked inactive, all their proxy users and their corresponding PATs are marked inactive. If a proxy owner is marked active, their proxy users remain inactive and would need to be individually marked active. An inactive proxy owner can't mark its proxy users as active.

Outside of the Blackbaud ID Environment

• When an application user is marked inactive on the Application User Summary Page, there is an option to provide a reason for the inactive status. In each of the following cases, a default reason is used to explain why each of the users are automatically marked inactive. Proxy users are marked inactive when their proxy owner is marked inactive. Proxy users are also marked inactive when failing to successfully login after 5 tries.

In Both Environments

• A proxy owner can't be deleted but can be marked inactive. To delete a proxy owner, each of their proxy users must be deleted before deleting the proxy owner.

Blackbaud CRM has improved usability by helping with assigning system roles and permissions to application users. An application user’s permissions within the system are controlled by the system roles they have, and the site and security groups granted for those roles.

Application users in Blackbaud CRM can have system administrator privileges granted which gives them overriding rights to all records and features. There are features granted to all system roles within Blackbaud CRM, Altru, and ResearchPoint. Each system role can be given to an application user with different site security or group security permissions.

Note: In Blackbaud CRM, proxy owners have system administrator privileges. Updating the system role permissions for a proxy owner who is also a system administrator won’t affect the system role privileges for any of their proxy users.

Note: A proxy user can only have a system role if its proxy owner does as well. If the proxy owner is a system administrator, the proxy user can have any system role.

When adding a System Role to a Proxy User

• Proxy users can be added via the Add System Role form from the proxy user Application User page or from the Add Application User to the System Role field.

• These methods are the same for any standard application user adding a system role to a proxy user or vice versa.

• Additional permissions checking takes place once the form is saved. If the form is canceled, the application user won’t have the system role added. If the form is saved but the proxy owner doesn't have the system role or the system role with sufficient site and constituent security permissions then an error is shown, and the proxy user won’t have the system role added.

  

Add a System Role for a Proxy Owner

• Adding a system role to a proxy owner is just like adding a system role to any application user. Increasing permissions of a proxy owner won't result in permissions being reduced below those of its existing proxy users. This doesn't require any additional checking, so there is no change to add a system role to a proxy owner.

Edit a System Role for a Proxy User

• Like adding a system role, editing a system role looks the same. However, checking takes place on save. It ensures that the system role exists for the proxy owner and the permissions for site and constituent security on the proxy user are the same or less. If the edit on the system role for the proxy user tries to assign higher permissions than the proxy owner, the same error message as above is shown.

Edit a System Role for a Proxy Owner

• When using the edit system role from the Application User page for a proxy owner there is a visual difference.

  

• The Proxy user list explains that when editing the system role on the proxy owner their proxy users who have that system role are affected. It then lists the proxy users who are affected. When the form is saved, the site and constituent security permissions for the system role on the proxy owner are saved. The site and constituent security permissions for their proxy users with the system role are updated. If the form is canceled no changes are made to either.

• In Blackbaud CRM, the proxy owner has system administrator privileges and access to everything regardless of what system roles may or may not be explicitly listed on their record. Changing the system role and permissions on the proxy owner doesn't have implications for the proxy user. The form looks as it did previously with no additional warning required. Updating the system role permissions for a proxy owner who is also a system administrator won't affect the system role privileges for any of their proxy users.

Delete System Role from Proxy User

• Reduction in rights is the same for any application user.

Delete System Role from Proxy Owner

• If a system role is removed from a proxy owner, it gets removed from all its proxy users. The delete action shows a warning that lists the proxy users that are affected.

  

• When the proxy owner is a system administrator, deletion of a role on the proxy owner doesn't affect their proxy users and no warning is shown.

Copying System Roles

• System roles can be copied from one application user to another using the existing functionality. In cases where application users are proxy users or proxy owners require additional permissions checking and handling.

Copy a System Role to a Proxy User When Their Proxy Owner is a System Administrator (Blackbaud CRM only)

• When the proxy owner is a system administrator, the proxy user can have any system roles with any system permissions. In this case it isn't necessary to do any additional checking before allowing the copy. The system roles, site and constituent security permissions are copied from the source application user to the target proxy application user.

Copy a System Role to a Proxy Owner who is a System Administrator (Blackbaud CRM only)

• This isn't allowed. The copy functionality isn't available for application users who are system administrators.

Copy a System Role to a Proxy User When Their Proxy Owner isn't a System Administrator

• When copying from a source application user to a target proxy application user, the source application user’s system roles are compared to those of the proxy owner. If the proxy owner doesn't have the system roles that the source application user has, the copy won’t be allowed.

  

• If the proxy owner has the system roles that the source application user has, copying is allowed. The target proxy application user has all the system roles of the source application user.

• To ensure the proxy user doesn't have site and constituent security permissions exceeding that of a proxy owner, the target proxy application user is given the site and security permissions of the proxy owner for each role - NOT the site and security permissions of the source application user. This differs from the copy functionality between application users where both system roles and site and constituent security permissions are copied from the source application user.

• The user is informed about this behavior when the target application user is a proxy user.

  

   

Copy a System Role to a Proxy Owner When They are Not a System Administrator

• System roles and site and constituent security permissions are copied from the source application user to the target proxy owner application user and all proxy users under that proxy owner.

  

• Previously, copy functionality didn't allow an application user to be both the target and the source for the copy. Now, a source application user who is a proxy user can't be copied to a target of their own proxy owner.

  

• A proxy user can be a source application user and be copied to a different proxy owner or proxy user.

Revoke System Administrator Privileges for a Proxy Owner (Blackbaud CRM only)

• If a proxy owner has revoked system administrator privileges, they may have added roles explicitly added to their record. The proxy owner is given any necessary system roles with all records permissions when their system administrator privileges are revoked. Proxy owners inherit all system roles belonging to their proxy users. The system roles on the proxy owner’s record can then be examined and permissions further reduced at this point.

• Granting and revoking system admin rights for application users repeatedly isn't recommended.

• If a proxy owner has system roles with various site and constituent security permissions is granted system administrator privileges and has those immediately revoked, their system roles, site and constituent security permissions are upgraded to All records.

  

Note: Proxy users can't access the webshell but are used by applications to authenticate. The applications can access the API endpoints for AppFxWebService and bizops.

Note: Edit Site Hierarchy (Blackbaud CRM only) By editing the site hierarchy, you can break the proxy user / proxy owner permission hierarchy rule and end up with a proxy user who has more permissions than its proxy owner. This is an irregular and unusual scenario. Changing the site hierarchy in such a way isn't recommended.

An application user must have permissions to use the proxy user management features. proxy users are application users with a role that have access to the Application User Page, and the ability to add an AD (Active Directory) or Blackbaud ID application user. Application users with system administrator privileges also have access to these features. Application users that don't have the appropriate permissions or aren't system administrators can be granted access to these features via a system role.

The proxy user management features are immediately available to the System Role Administrator - system role. Any application user can be added to this role or any other system role within Blackbaud CRM by accessing Security > Application Users and making the appropriate selections.

A proxy user is a non-interactive user supported by third party software, that needs to authenticate with the Infinity platform.

A regular interactive application user needs a username and password to authenticate. Sometimes those users have added authentication requirements such as MFA (Multifactor Authentication), or database authentication.  A proxy user needs a username and PAT (Personal Access Token).

PAT Add

Only a proxy owner can add a PAT to their proxy user.  On the Application User Summary Page, a proxy user has an added tab Personal Access Token with an available Add PAT action.

Selecting Add opens a dialog box.

Once the PAT is generated and displayed, the proxy owner must copy the PAT because it won’t be available in the future.  The PAT needs to be copied and pasted into the third-party software.  The name of the service should be entered in the dialog box.  This is the nickname for the PAT that is displayed to the application user when they are looking at their PATs.  To ensure that the PAT has been copied correctly, the proxy owner can use the copy button and confirm copying with the checkbox.

If the PAT add is canceled, a PAT won’t be created, and the PAT previously copied can’t be used to authenticate.  If the PAT is created, it gets stored and encrypted. The requirement to copy using the copy button ensures that the PAT remains secure. The PAT won’t be visible within Blackbaud CRM or Altru again.

The example PAT above has been added, is currently active and within date.  The PAT is unique to the proxy user for which it was added within the Blackbaud CRM, Altru, or ResearchPoint database where the proxy user exists.

Note: The PAT can only be used to authenticate for that proxy user to gain access to information within that database.

Only a proxy owner can add a PAT for a proxy user that belongs to them.  If an application user tries to add a PAT for a proxy user that isn't theirs, they are shown an error.

A proxy user can only have 2 active PATs.  If a proxy user already has 2 active PATs and they need to add a new PAT, the proxy owner must first revoke one of the existing PATs.

PAT Revoke

An active PAT can be revoked. This is a one-way process.  A revoked PAT isn't valid to use, and the proxy user won’t be able to authenticate.  The proxy owner has the right to revoke a PAT. Another application user with suitable privileges, such as a system administrator, also has the right to revoke a PAT.

When a PAT is revoked manually using the revoke button, the user can enter a revoked reason.  This appears in the PAT data list for the process user.

The PAT data list can be configured to show both active and revoked PATs.

PAT Revoke Reason Code Tables

Any reason entered by the application user for PAT revocation is added to the PAT revoke reason code table.  These reasons can also be accessed and edited in their code tables found in the Administration functional area within Blackbaud CRM under Data Code Tables.

Reason codes in this table are displayed in the drop-down list on the PAT revoke edit form.  A reason can be selected at this time, or a new reason can be added.

There are 2 default reason codes that are already provided.  These are used by an automatic process.

1. The PAT is expired - When the Proxy User Management, Management Personal Access Tokens global change is run and finds that a PAT is past its expiration date.

2. The User is inactive - When the proxy user is marked inactive, all PATs for that proxy user are automatically revoked.

An application user is free to select one of these default reason codes when providing a reason for the PAT revocation.

If a PAT revoke reason code is added to the code table by a user but isn't actively in use the reason code can be deleted in the Administration code table.  The 2 default reasons can be edited but not deleted because they are required by automated processes.

When revoked PATs are displayed in the PAT data list, they can't be revoked a second time and the revoke button is grayed out.

A user can manually revoke and mark their PAT as expired. A global change makes it possible for users to iterate through all PATs and revoke any that have expired. When revoked with this automatic process, the default reason of PAT is expired is used. Users can edit the expired default reason text in the code table.

This update fixes multiple defects and issues. For details, review the patch notes for service pack 32.