​​​​​​​​​​​​​​​​​​​​Release Objectives

The main objectives for the implementation of the Cobalt Release 3.4 project were to​:

  1. Add more features to the product and build on existing functionality to continue to gain momentum in the association and certification management software markets
  2. Fix priority and lingering product bugs, and reduce the overall bug count in the product backlog
  3. Improve performance of the product to allow us to more confidently deploy customers to the Microsoft Dynamics 365 online environment

Expected Benefits

For each release, we outline the expected benefits if we achieve the objectives and success criteria of the project. The expected benefits for 3.4 were:​

  • Cobalt Support & Existing Customers – Existing customers will benefit from us fixing key bugs and reducing the overall number of bugs in the Cobalt Product backlog. The new features implemented include often requested items from existing customers, including updates to our form process and web elements. Both items should improve overall customer satisfaction and reduce the burden on the support staff
  • Cobalt Implementation Teams / New Customers – The planned architectural updates will make the product more flexible when writing code to meet customer requirements. Additionally, several of the new features are aimed at making the product easier to configure for Cobalt consultants and customers. These efforts should result in less development and configuration time as well as fewer bugs during customer implementations. This will also result in higher customer satisfaction as well as happier developers and consultants
  • Sales / Prospective Customers – The sales team will have new features to show off to prospective customers including several items that are frequently requested by prospects. The new, more flexible configuration items will also allow the sales team to more quickly configure demos to meet semi-custom requirements. Both will increase our chances of winning deals and hopefully reduce the amount of time spent preparing for demos

Form Redesign

General Notes

In release 3.4, we overhauled Cobalt’s Form functionality. This included the implementation of a form designer for end users to create their own forms with fewer steps.

The Form Designer can be launched by going to [your portal URL]/WebElementDesigner.aspx or from the Form Entity in Microsoft Dynamics 365 by clicking the Form Designer ISV Button.

From the designer, users can create or update existing forms, select an entity to map the form to, and add pages, sections, questions, or controls which are not mapped to the entity but will be saved as part of the form response.


Sections, pages, and questions can now be edited directly from the designer.

There are three types of pages:

  • Question – Displays the question control
  • Text – Displays text only
  • Summary – Displays a read-only summary of the questions answered previously with an option to return to the page to change answers

For a standalone form to function properly, forms should be set up with one of each page type. This does not need to be done for forms used in application processes.

Creating a Page Title and Page Instructions in the designer will create a related page text record in Microsoft Dynamics 365 and set a new lookup on the page record in Dynamics to the parent Form. This means a single form can have page text unique to each page. Previously, page text was shared across all pages of a form.


Questions on forms will maintain their format requirements from Dynamics 365. For example, if the emailaddress1 field is added to a form, the question will be created with the Format and Format Expression appropriate for an email address field.

Users can also specify a question as a Match field. This allows users filling out a form to update existing records in Dynamics 365 based on a unique match.
Mappings will now be automatically generated when existing fields are added to the form. Previously, users had to manually create mapping logic.

Unmapped Controls

There is a wide variety of control types available. Highlights include: Password (masked plain text); Dynamic Option Set that updates based on picklist values in Dynamics; single document uploads with or without previews; multiple document uploads with or without previews; and CAPTCHA to validate a robot is not attempting to submit a form.

Web Element Enhancements

General Notes

We created a new entity to house the configuration and all relevant information for Web Elements. The web element generator can be launched from this entity in Microsoft Dynamics 365 to create new web elements and update existing web elements.

We added the ability to include custom JavaScript and CSS for web elements so that customers can control styling and page behaviors for web elements.

We also added the ability to create Form and MyForm Web Elements. This allows users to design forms and make them available to collect data anywhere on their CMS. The My Form Web Element will map ad-hoc forms to the logged in contact by default and maintain the context of the logged in user.

Grid and List Web Element Enhancements

We updated the Grid and List Web Elements to allow users to edit or view additional details about records in the grid or list. A Form can be selected in the Web Element designer to define what details will be displayed or edited when a user drills into a record from the list. The ability to export records to a csv file is now available for Grid View web elements as well.

Add Configured Elements to the Standalone Portal

We added the ability to add configured web elements to the standalone portal. This will allow flexibility for our customers that have not moved to Web Elements but would like to be able to easily build custom pages for their portal. With the addition of the Form and My Form Web Element Generators, customers can build custom pages and place them in their portal sitemap, all through the UI without any additional development.

Revenue Recognition

General Notes

We added Revenue Recognition to Dues (and Membership Applications with Dues), Classes, and Subscriptions. If any of these processes have a revenue recognition elevator hooked into them, or if a product on the order has a WIP and Revenue product-specific GL account, revenue recognition records will generate when invoices are created. Each revenue recognition record with have a recognition date set.

A CRON job will run on a scheduled bases and automatically recognize/move the revenue from the WIP account to the Revenue account on the appropriate recognition date.


The following fields were added to the Dues Cycle to control how revenue is recognized:

  • Schedule – Recognize revenue monthly or quarterly
  • Reconciliation – Determine whether revenue is recognized for months or quarters in the past when the invoices are generated or whether it is split up into upcoming months or quarters

Each line item that is eligible for revenue recognition will have its own set of revenue recognition records generated under the invoice.

Membership Applications

Revenue evaluation happens when the application is completed, the fee has an associated dues option, and the member type has the Membership Activation field set to automatic.

Membership Applications with Termed Dues will defer recognizing any revenue until the membership application is completed.


A Revenue Recognition Date field has been added to Meetings and Classes to control when revenue is recognized.


The following fields were added to the Publication entity to control how revenue is recognized:

  • Schedule – Recognize revenue monthly or quarterly
  • Reconciliation – Determine whether revenue is recognized for months or quarters in the past when the invoices are generated or whether it is split up into upcoming months or quarters

Manual Discounts

We added fields to the revenue recognition record to take manual discounts into account.

Elections, Awards, and Abstracts

General Notes

Engagement Dynamics now includes a new module: Elections, Awards, and Abstracts. In the Cobalt Membership module layer, we also added relationships to make this functionality available for committee nominations.

The module includes the ability to nominate people, create them as candidates (or finalists), and then allow users to vote on those candidates. Elections can be set up to allow self-nominations or not, allow write ins or not, or allow single or multiple nominations.

The module includes an election list page, where users can navigate to see elections that they are eligible to nominate or vote in. Forms are also available as part of nominating or voting. End users will be able to navigate to the My Nominations page and see a history of their nominations.


Voting can be completed in one of three ways. A user in Dynamics 365 will select one of the following for Voting Scale on the Election record:

  • Single Scale – Presents the end user with one question, “On a scale of [MIN] to [MAX], how much do you support [NAME]?” The end user will select a rating from a series of radio buttons. MIN, MAX, and NAME are set in Dynamics 365
  • Multiple Scale – Displays a series of questions predefined in Dynamics 365. The end user will select a rating for each from a series of radio buttons. Questions, MIN, and MAX are set in Dynamics 365
  • Default – Presents the end user with one question, “Would you like to vote for [CANDIDATE NAME]?” The end user will select either Yes or No. This option is selected if the voting type is left empty or if the application requirement type is not correctly filled out for one of the above options (e.g. the Election is Single Scale, but it does not have a MIN set).

Election List Web Element Designer

This new Web Element Designer allows for customization of the Election List page.

The following are configurable through the designer:

  • Determine what elections display in the list by selecting a query from Dynamics 365
  • Update the Submit button text
  • Update certain default text on the list page

My Nominations Designer

This new Web Element Designer Allows for customization of the My Nominations list page.

The following are configurable through the designer:

  • Allow the end user to filter based on a saved query from Dynamics 365
  • Update the Edit button text
  • Update the Withdraw button Text

Queued Payments

General Notes

We added the ability to Queue Payments for processing. This will assign payments to a queue by setting them to the “queue” status reason. The CRON will run on a scheduled basis to process and apply any queued payments. Failures will be tracked as the CRON continues to try and apply those payments.
We updated membership and certification applications to recognize queued payments as being complete.


General Notes

We created an Alert Control that can be used across the product: in Dynamics 365, on the Portal, and as a standalone Web Element.
The Alert entity has the following fields to control when and where alerts display:

  • Begin date
  • End date
  • System query – determines what records the alert will display against
  • Priority
  • Sort order – alerts will be sorted by priority, then sort order
  • Display in CRM / display on portal

To embed the Alerts as a standalone Web Element, customers can navigate to Profile Elements > My Alerts.

Web Elements – Custom Ecommerce

General Notes

We implemented a new Generic Application Wizard, referred to on the portal as Custom Ecommerce. The Generic Application Wizard allows for new application wizards to be created without custom development. The idea is that the current hardcoded logic can be replaced with configurable data by the end user. Specifically, we are using the web element designer to configure the generic application wizard. This will give customers more flexibility and control over their applications.

The Generic Application Wizard follows the same logical structure as our other, preexisting application wizards. It is based on a Web Element Type and includes Web Element Fees (and payment if required). All user input data is based on Forms specified on the Fee or on the ecommerce wizard type (if no fees) and the user can review their application on a summary page prior to submitting and receive a receipt upon submission.

Store Web Element

These Custom Ecommerce Applications are exposed to the end user using the Web Element Type entity and the Store Web Element. The end result is similar to Cobalt’s pre-existing portal store, but customers have more flexibility and control.

The designer for this web element allows users to specify the fields they want to be displayed for each entity as well as an image, and includes a link to a details page. Users are able to specify a query that determines what records display in the store.

The page includes a search function and supports multi-currency.

The following are configurable:

  • Text of the Detail button
  • Allow coupon redemption
  • Show slim credit card control – for fast checkout, show minimal credit card input fields during payment
  • Require login for purchase – allows end users to sign up and paying without logging in
  • Text for the Buy Now button

Store Details Web Element

The Store Details Web element is a detailed page of an individual Web Element Type. This allows each individual Web Element Type to be embedded if that is preferred over a full list.

This page is similar to the product details page and shows the details of the web element type. It can be configured to display specific information about the fees.
The following are configurable:

  • Allow coupon redemption
  • Show slim credit card control – for fast checkout, show minimal credit card input fields during payment
  • Require login for purchase – allows end users to sign up and paying without logging in
  • Text for the Buy Now button

Termed Dues

Activate Dues Item Workflow

We updated the Activate Dues Item workflow to only run on demand. The process now has a branch that looks for Termed Dues.

Activate Dues Item Cron Job

Updated the CRON job to account for paid termed dues when activating dues items. Previously we were only considering dated dues items.


Social Sharing Buttons

We added Social Icons to the following pages:

  • ~/Meetings/Registration/ClassDetails.aspx
  • ~/Meetings/Registration/MeetingDetails.aspx
  • ~/Subscriptions/PublicationDetails.aspx
  • ~/Sales/Catalog/Detail.aspx
  • ~/WebElements/WebElementDetails.aspx

Miscellaneous Bug Fixes & Features

A number of miscellaneous bug fixes and features were included in Release 3.4. Highlights include:

  • Added sorting for meeting, class, and subscription fees on the portal
  • Resolved an infinite loop/timeout issue with meeting registrations
  • Resolved a loophole allowing meeting registration to be generated past the Max Count when Waitlisted was set to No
  • Improve performance by improving asynchronous plugin efficiencies, updating portal code to save images locally, and updating retrieves to only pull back necessary columns when generating sales orders
  • Resolved issue where timeouts in plugins forced sandbox restarts
  • Corrected additional miscellaneous issues with tax tables, coupons, failing workflows, inactive meetings and activities, payments, SSO, and UX