Release Objectives
The primary objectives for the Cobalt 3.8 Release were to:
- Add new features to our product so that we can meet a greater number of customer requirements with our standard functionality and be in a stronger position to compete for new business.
- Improve the user experience for staff by streamlining existing processes.
- Fix priority bugs and close gaps in functionality identified by support, implementation teams, and customers as well as items uncovered by our automated testing sprints.
Expected Benefits
The Cobalt 3.8 release will be considered a success if the following criteria are met.
- A contact with the appropriate permissions can perform the following actions on behalf of an organization when logged into the member portal – manage the roster of contacts, membership applications/renewals, and viewing order history and paying open orders.
- Expand our form functionality to allow for more flexibility without custom development including the ability for staff members to be able to create forms that allow for adding a lookup field, Rich Text in the page instructions, and the ability to clone forms with a user-friendly wizard.
- All priority bugs and features selected for inclusion in the release are implemented or fixed during this project.
Supported CRM Versions
D365 On-Premises
- 8.X Version: 8.2.28.11 (April 2021). This is the most recent version of 8.2 and we do not expect any future updates because the end of mainstream support for this version was January 12, 2021.
- 9.X Version: Not Supported. We are not supporting 9.0 on-prem because it is no longer supported by Microsoft. We plan on supporting 9.1 on-prem with a minor version release.
D365 Online
We continue to support the latest version of Dynamics 365 Online with the 3.8 release. Note that regression testing was completed on the server version 9.2.21112.00141, but these builds often vary based on the region the customer’s tenant is located in. For implementations or projects that are targeting an online go-live, it is best to patch any on-premises D365 (i.e. dev and/or stage) to the latest 9.x version as to have the smallest version gap between what is on-premises and what is online.
Cases and Background
Admin Portal
A large part of this release was improved functionality for trade associations and other account-based membership organizations. As of this release, individuals can be affiliated with accounts via a contact affiliation. Contact affiliations can be created one of three ways:
- A portal admin adds the contact to their company roster via the ‘Manage Roster’ link
- An individual signs up for a profile through the portal and their email matches an active account domain
- Example: The account “Cobalt” has a related account domain of cobalt.net. When a contact signs up for a profile and uses an email that ends in @cobalt.net, a pending contact affiliation is automatically created
- An individual signs up for a profile through the portal, and they associate themselves with an account after the fact through the ‘Update My Profile’ self-service feature
- If the person searches for an account and cannot find the correct account, they can either add a new account, which they will be automatically affiliated with, or they can receive a validation message to contact an administrator
If a contact affiliation is created by a portal admin or via a domain match, they will receive an email with a verification link. Upon clicking the link, the contact affiliation will be approved and the individual will be prompted to either create a new portal account or log into an existing one.
If a contact affiliation is initiated by the individual (without a domain match), an admin for the account will need to approve the request.
A contact affiliation can exist merely to link a contact and an account, or a contact affiliation can be given different permissions (called Account Portal Roles) to act on behalf of an account. Cobalt clients can create their own account portal roles by mixing and matching the different permissions. For example, if a client wants to create an account portal role for a global administrator, they would create a new account portal role and enable all of the different permissions. The four different permissions that can be enabled/disabled are:
- Manage Account Details
- Pay & View Account Orders
- Manage Roster
- Manage Organizational Membership
Once an account portal role is created, portal admins can assign these various permissions to contacts on their company roster via the portal if they so choose.
Portal-Facing Features
| Case | Title | Description |
| 32084 | Manage Roster – Pending Request Actions | This case allows for an admin with ‘Manage Roster’ permissions to act upon pending contact affiliation requests (either incoming or outgoing). |
| 32083 | Manage Roster – Current Roster Actions | This case allows for an admin with ‘Manager Roster’ permissions to add new contacts to the roster, remove existing contacts from the roster, and edit existing contacts affiliation relationships. |
| 32081 | Manage Roster – Add Contact Lightbox / Toggle Permissions Lightbox | This case provisions the lightbox that appears when an admin adds a contact to their organizational roster. |
| 32079 | Manage Roster – Current Roster Grid | This case provisions the ‘Current Roster’ grid that shows all active contact affiliations to an admin with the ‘Manage Roster’ permissions for a certain account. |
| 32078 | Manage Roster – Pending Request Grids | This case provisions both the ‘Pending Individual Requests’ and ‘Pending Verification Requests’ grids that show all pending contact affiliations to an admin with the ‘Manage Roster’ permissions for a certain account. |
| 32077 | Manage Roster – Scaffolding | This case provisions the three pages necessary for an admin to view roster information: ~/Account/Roster/PendingRequest.aspx, ~/Account/Roster/CurrentRoster.aspx, and ~/Account/Roster/RosterConfig.aspx. |
| 32070 | Organization Tile – Designer | In this case, we added a designer page for the new organization tile that appears when a contact has an active contact affiliation with an account. |
| 32069 | Organization Tile – Core Imp | This case controls how the new organization tile displays based on if a person is affiliated with multiple accounts and the permissions they are awarded for those accounts. |
| 31681 | Ability to Edit Account Details (Address, Phone Number, etc) | This case allows an account admin with the ‘Manage Account Details’ permission to update information about the account such as phone number, email, website, and address information. Organizations can also configure additional questions if needed using Cobalt’s form functionality. |
| 32923 | Manual Self Affiliation – Scaffolding | This case stubs out the pages needed for the self affiliation process (when an individual wants to affiliate themselves with an account). |
| 32924 | Manual Self Affiliation – Current Affiliations | This case determines what the ‘Current Affiliation’ page looks like for an individual, depending on if they have active affiliations with accounts and the service configuration outlined in FB case 32023 is set to ‘True.’ |
| 31684 | Ability for account admin to pay and view order history on behalf of account | This case allows an account admin with the ‘Pay & View Account Orders’ permissions to switch between their personal orders and account orders on the portal. |
| 32925 | Manual Self Affiliation – Add Affiliation | This case provides the process in which a contact would affiliate themselves with an active account without using the domain matching functionality. |
| 32065 | Email Domain Verification – Domain Configuration | This case provisions the Domain Configuration page. This enables an admin with ‘Manager Roster’ permissions to add, update, and/or delete account domains. When an account has an active account domain, any contact record created with an email address that matches an active account domain record will have a related, pending contact affiliation created, connecting the contact and the account. An account can have multiple domains, but a single domain can only be related to a single account. |
| 32926/33165 | Manual Self Affiliation – Add Account | This case allows individuals to create accounts for which they are the admin for depending on the value of a service configuration. If the service configuration is set to false, contacts will not be able to create a new account through the profile update process. If the service configuration is set to true, contacts will be able to search for an account through the contact affiliation creation process, and if they can’t find the account, they can create one. The contact affiliation will automatically be set to Active: Active and awarded any account portal roles where Auto Assigned for Account Creator is set to ‘Yes.’ |
| 34182 | Domain Match Verification Toggle | This case makes it so there are different verification checks in place, depending on how a contact is affiliated with an account. If a contact is created by an admin via the ‘Manage Roster’ process, a pending contact affiliation will be created. The ‘Require Admin Approval’ field on the contact affiliation will be set to no, and the contact affiliation will go to Active: Active once the link in the contact level email verification email is clicked. If a contact affiliation is created via a domain match, the contact affiliation level email will go out to the contact. If the ‘Admin Verification of Domain Match Required’ field on the settings record is set to ‘No,’ the contact affiliation will go to Active” Active upon the contact clicking the link. If it is set to ‘Yes,’ the admin for the account will still need to approve the affiliation request before the contact affiliation goes to Active: Active. |
| 32932 | Resend email verification option for pending contact affiliations created via account domain match | If a contact goes through the profile creation process and they use an email address that matches an active account domain in the system, there is a chance their verification email might go to their junk inbox. We added a way to resend the email in case this happens. |
Back-End Logic
| Case | Title | Description |
| 31689 | Contact Affiliation entity | This case creates the contact affiliation entity. This is the entity we use to connect a contact to an account. Contacts can have multiple contact affiliations with different accounts. Additionally, we are using this entity to track who initiated the contact affiliation request and the start/end dates of the affiliation. |
| 31687 | Account Portal Role entity | This case creates the account portal role entity. Contact affiliations can have related account portal roles. The four base permissions (boolean yes/no fields) are: manage account details, pay & view account orders, submit membership application on behalf of organization, and manage roster. |
| 32062 | Email Domain Verification – Customizations | This case creates the account domain entity. Accounts can have multiple account domain records. When an account has an active account domain record (ex: cobalt.net), any contact that is created with an email address that matches that domain record (ex: annie.hall@cobalt.net), will automatically have a pending contact affiliation created that connects the contact to the account. |
| 32080 | Contact Affiliation – Manage Roster Plugin | When a contact affiliation goes to Active:Active, we set the start date today. When a contact affiliation is deactivated with any status reason, the end date is set to today. |
| 32066 | Email Domain Verification – Email Workflow Configuration | This case is a configuration only case that sends out an email to a contact to verify a contact affiliation. Please note this is different from the pre-existing contact level email verification functionality. |
| 32064 | Contact Affiliation – Email Confirmation Page | This case creates an email verification URL on the contact affiliation record. This URL is populated when a contact creates a portal profile with an email address that matches an active account domain in the system or when an account admin adds a new contact via the ‘Manage Roster’ functionality. Depending on the state of the link, the contact affiliation will either approve the contact affiliation or throw a different validation message. |
| 32063 | Email Domain Verification – Profile Setup | This case creates a pending contact affiliation between a contact and an account when a contact record is created with an email address that matches an active account domain record in the system. For more information, please see FB 32062. |
| 32867 | Update cobalt_initiator option set and logic when contact affiliation is created from a domain match | This case updates the initiator option set on the contact affiliation record from the default to ‘System – Domain Match.’ |
| 32588 | Create new contact affiliation when emailaddress1 is updated | This case creates a pending contact affiliation record when the email address of a contact is updated to match an active account domain in the system. Please note FB case 32063 was just for when a contact affiliation is created. This case is for when the email address is updated. |
| 32023 | Roster Configuration | This case creates a service configuration that shows/hides the ‘Organization’ tab when a contact goes to update their profile on the portal. However, a contact will still see the tab even if this service configuration is set to ‘False’ if the contact has related active contact affiliations. If this is the case, we will hide the ‘Deactivate’ and ‘Add Affiliation’ buttons on the page. |
| 32587 | Create/Update contact record when contact affiliation is approved | This case creates a new contact or matches an existing contact upon an individual verifying their email for a pending contact affiliation when a contact is added by a roster admin. |
| 32913 | Require Affiliation Verification and Require Email Verification on Settings Record Logic | This case suppresses the email verification email that is sent out at the contact affiliation level if ‘Email Verification Required’ is enabled. Please note the ‘Email Verification Required’ functionality was built before the Cobalt 3.8 release. |
| 32921 | Enable/Disable ability for account admin to account domain records via the portal | This case shows/hides the Domain Configuration page where an admin can update account domain records on behalf of an account depending on the value of a service configuration. |
Portal
This release also included a number of highly requested features that extend existing portal functionality. We are especially excited about the improved Cobalt form functionality. Cobalt Forms now support Rich Text in the ‘Page Instructions’ section and the selection of a lookup field.
We also fixed a few small issues that were impacting the portal user’s experience when using our eCommerce functionality. These changes will make for an even smoother check-out process, leading to an even greater conversion rate.
Features
| Case | Title | Description |
|---|---|---|
| 16626 | Forms – Add Lookup Type Question to Forms Portal Side | This case allows clients to add lookup fields to Cobalt forms. |
| 33653 | Ability to download web element grid/list in an excel template | We are now able to download a web element grid/list as an excel template on the portal. This will allow external portal users to download a streamlined report as opposed to just a Excel sheet. |
| 33664 | Increase size of profile picture on portal | The profile picture size on the portal is now configurable via the Web Element Designer. Please note the default is 90px X 80px and we recommend a max of 225px X 150px. |
| 34210 | Upcoming Events Tile: Empty Message/Hide When Empty | This case added a configuration option where the Web Element Designer can either hide the ‘Upcoming Events’ tile completely if empty, or it can display a message that tells the portal user there are no upcoming events. |
| 20112 | Merge Text in Alerts | This case added a service configuration property that allows for merged text in portal facing alerts. Please note we only support a single alert with merged text at this time. |
| 27301 | Forms – Add WYSIWYG Editor to Text Areas | This case enables us to use Rich Text on Cobalt Form pages, specifically for the page instructions section. Please note this case only supports Rich Text for the page instructions– it does not allow for Rich Text input provided by the portal user. |
| 34571 | Implement Cache Behavior of Alerts | Adding in the ability for the “cache behavior” flag to be respected on the home page for the Alerts entity. |
Bug Fixes
| Case | Title | Description |
| 25219 | Web Elements Custom Form Mapping for Linked Entity Failing | This case fixes a known issue with mapping form responses back to a custom entity when using a custom e-commerce web element. |
| 32954 | Home Portal Tab Does Not Change Color Once You Navigate Away from Home and Back | This case fixes an issue where the ‘Home’ portal tab did not change colors as expected when you navigated away from it and back to it. |
| 31690 | Update the portal layer’s /Sales/Catalog/Detail.aspx page | Previously, if a portal user who was not logged in browsed the online store and clicked the ‘Login & Account Set Up’ button on the item details page, they would not be redirected to the same ‘Details’ page once they logged in. They are now correctly redirected to the previous page they were on before logging in. |
| 27802 | /Meetings/Registration/Registrant/MemberSearch.aspx grid does not allow nav beyond page 1 | Previously, paging was broken on the Member Search page when someone was trying to register a group of people for a meeting. We are now limiting the number of results to twenty people on a single page. If your results return more than twenty people, you will see a validation message that reads “Not all results are being shown; if you do not see who you are looking for, try further refining your search” |
| 33175 | ”X” on Search Fields and Other Text Input Fields Does Nothing | This case fixed an issue where clicking an ‘X’ on a text field on the portal didn’t do anything. This now clears out the field as expected. |
| 32262 | All My Custom Elements Will Throw Error If Accessed Prior to Logging In | This case fixed an issue where the portal would throw an error if a ‘My Web Element’ was accessed before someone was logged in. |
| 32833 | Event Calendar Control & Upcoming Meetings Control No Longer Render | This case removed an invalid Event Calendar Control in the Web Element Designer. |
| 27685 | Order Source generated URLs not evaluating merge text | This case prevents a contact from paying for a dues item if the merged text in the order source cannot be resolved. Previously if this was the case, the page would throw an error. |
| 28440 | Web Element CSV Download respects commas in field values | This case enables CSVs that are downloaded from a Web Element grid/list to respect commas included in the sheet. |
Core
This release included a few core features meant to improve the backend functionality. We have done a number of these features for clients in client implementations, and we were able to fold them into the client layer. We are really excited about the ability to clone forms.
We fixed a couple of small bugs. The bug we fixed that we foresee having the biggest impact on clients is FB 33025, which will prevent cron schedules from starting before the previous one finishes.
Features
| Case | Title | Description |
| 29701 | Ability to Clone Cobalt Forms | Cobalt forms can now be cloned without any custom development. |
| 33343 | Word and Excel Template Proxy Entity | This case creates a new entity titled ‘Cobalt Document Template’ that will make it much easier for Cobalt to implement portal facing word and excel templates during client projects. |
| 32579 | Protection Against Read-Only SQL Injection Attacks | This case formally makes the Cobalt web applications protected against read-only SQL injection attacks by making use of built-in libraries instead of using our own code to protect against said attacks. |
| 25961 | Reattempt Sales order payment workflow creates duplicate batches when run on multiple payments at once | There was an issue where running the ‘Reattempt Sales Order Payment’ workflow on multiple payments at once first thing in the morning would result in multiple batches. We added logic that pregenerates the batches a couple of days before they are needed, and then cleans them up a couple of days after if there are no batch items in that specified batch. Please note this functionality is additive– we left the original batch creation logic in place if a client opts to not use this feature and as a failsafe in the event the cron does not run for whatever reason. |
| 34089 | Dues Renewal Performance Improvements: Sales Improvements | A part of our effort to improve dues re-calculation, we took the time to improve our overall price calculation for orders and invoices. To achieve this, we decided to no longer leverage OOTB price calculation that Dynamics would otherwise do for us automatically. This allowed for us to cut down on the number of overall plugin steps being executed by both us and Microsoft, and to have more visibility and control as to when different fields are calculated. |
Bug Fixes
| Case | Title | Description |
| 25938 | Core: Queried Requirement for Web Element type missing Query navigation in UCI | This case fixed an issue where the ‘View Query’ button was missing in the UCI when a web element type had a web element requirement where the mode = query. |
| 33025 | Cron Schedules Running over each other for the same task | This case fixed an issue where cron schedules weren’t waiting for the previous cron schedule to finish before starting the next scheduled cron schedule. We are now making sure cron schedules under the same job will not trigger until the currently running schedule is completed. |
| 25090 | Alert description Text displays raw HTML in CRM | This case fixed an issue where CRM-side alerts were displaying with Rich Text HTML. |
| 33431 | CORE: Monthly Deposit Report Showing Duplicate Payments | This case corrected an issue where the Monthly Deposit SSRS Report showed duplicate payments when a payment record had two related batch item (one for ‘create’ and one for ‘update’) |
| 33695 | Incorrect Criteria for Cobalt System View: Partially Applied Payments | This case corrected the system view for ‘Partially Applied Payments’so the criteria in the query is now unapplied amount is greater than $0. |
| 32467 | Require Login for Purchase = No Web Element Option Still Requires Login | This case fixed an issue where a custom eCommerce web element where require login for purchase was set to no still required a login. |
| 34184 | Question Sort Order Resetting in Web Element Designer | This case corrected an issue where setting the sort order for different questions in the Form Designer lead to inconsistent behavior. |
| 34056 | Running CleanupSystemGeneratedQueries Message Does Not Clean Up System Queries | This case corrected an issue with the “CleanupSystemGeneratedQueries” message, so we can now schedule the clean up of saved queries via a cron. |
| 31583 | Launch Designer Script Error | This case fixed an issue where the ‘Launch Designer’ button on the Cobalt Form entity would initially display an error in an Online environment, forcing the user to relaunch the Designer a second time. |
| 19067 | Canceling Class Registrations from portal decreases Current Registrations on Class twice | This case fixed an issue where canceling a class registration from the portal decreased the current number of registrations on a class twice. |
Membership
The majority of membership features we implemented were developed alongside the admin portal functionality. We now fully support end-to-end organizational (account-based) membership completely out of the box.
We fixed a couple of minor issues that should make the dues renewal process smoother for both staff and portal users.
Features
| Case | Title | Description |
| 32072 | Account Based Membership – Customizations | If a membership application is submitted by an admin on behalf of an account, we are tracking who submitted it via a lookup on the membership application. If a dues item is paid by an admin on behalf of an account, we are tracking who paid for that dues item via a lookup on the dues item record. |
| 31680 | Account Membership Information Tile | This case updates the existing ‘Membership Information’ tile with a configurable property within the designer to indicate it’s customer target (contact vs. account). If the target is set to contact, the tile shows information about the contact’s membership. If the target is set to account, the tile shows information about the account’s membership. Please note the information that is presented in this tile for an account is dependent on the account portal role for that contact affiliation (FB case 31687). |
| 32073 | Account based membership – Initial Application Update | This case updates the membership application process on the portal to target the account as opposed to the individual if applicable. |
| 32074 | Account based membership – Membership Renewal & Submitted By | This case updates the dues renewal process on the portal to target the account as opposed to the individual is applicable. It also sets the lookup fields from FB case 32072 where needed. |
| 34062 | Dues Renewal Performance Improvements: Dues Renewal Exclusive Updates | The specific location that we were targeting to improve the performance of with this case was to reduce the overall time it takes for the system to recalculate the order associated with the dues item when its dues option was changed during the OnContinue event of the DuesOption.aspx page. |
Bug Fixes
| Case | Title | Description |
| 27657 | If Dues Product: Amount Editable = No, then Required flag not respected | Our dues process now supports non-editable, but also non-required dues products. This enables organizations to set up a dues product that can be opted out of, without being able to change the amount. |
| 28443 | Ensure Dues Option is saved on Continue on ~/DuesOption.aspx | This case is related to the dues renewal performance work we did in 3.8, but this specifically ensured a dues item is saved and the order is refreshed on continue of the Dues Option page. |
| 31194 | Generate Dues pre-flight fails if Does Not Contain operator field is null on Text Field | This case fixes an issue where the Generate Dues Pre-Flight check would fail if the master query included a “does not contain” or a “contains” operator. |
| 12437 | Back button on Membership Renewal Order | This page hides the back button on the order summary page in the event there is only one dues option available for the user to select from the dues option page and there are no chapters tied to the renewal process. |
| 32779 | Dues Cycle Long Running Processes Requiring Full Trust | This case updated both the GenerateDuesItems and TerminateMemberships processes to run in full trust, meaning we will no longer see timeout issues associated with these messages. We also added additional logging for easier troubleshooting. |
Certification
We implemented two portal-facing features that will allow for a smoother initial and continuing certification experience.
Features
| Case | Title | Description |
| 34202 | Add Additional Sorting to Certification Application Requirements | Previously, the certification application requirements on the receipt page were initially ordered by status. We’ve added additional fields to allow for a more configurable sorting experience. |
| 34203 | Check Certification Status Should Bring You Straight to Receipt Page | Previously, upon clicking ‘Check Application Status’ on the portal, a portal user was taken to an intermediary page, and then they had to click again to be taken to the correct page. This case eliminated that bridge page for an improved UI experience. |