HOC 3.0.7.13 Release (Feb 21, 2019)
This release completes the significant internal improvements we've done to HOC to migrate to using the Rest API which will result in better performance, and more flexibility for the future. It also sets the stage for development of future mobile applications! There are also a number of improvements to the public site, the ARS and forms. Here's the highlights of this release:
We've always recommended using Salesforce Files as the best way to make documents available via the public site, but we've now made it possible to link files that are uploaded directly into the CMS as well. There are pros and cons to each approach, but now you have multiple choices.
To learn about both ways of linking to documents and the pros and cons of each approach read this article!
1. Previously, in the ARS you couldn't set logical conditions to branch the workflow based on input to multi-picklist fields. (only to regular picklists). Now multi-picklists are supported for branch logic.
If you set the condition to equal to -- then if the value is one of the values in the multi-picklist it will be considered true.
If you set the condition to not equal to -- then if the value is not one of the selected values in the multi-picklist it will be considered true.
2. Additionally, when placing a Multi-Picklist on a form (in the ARS or in a stand-alone form), you can optionally require that the user select a minimum number of options and/or a max number of options when submitting an answer to that question on the form. If they do not submit the right number of selections on the multi-picklist, a message is displayed "Please select between [minNumber] and [maxNumber] option(s)." If these values are left blank, the user can select just one option (if the field is required), or none (if the field isn't required)
Previously, when creating an ARS workflow for partner registration - you could only map data to the contact record of the person submitting the form). Now you can choose to create an ARS workflow for partner registration that maps to either contact OR account. Or both! It makes a lot of sense to put additional information about the organization itself on the account record. And now you can! How sweet it is!
1) Headers now visible in exported summary reports: When a report was a 'summary' report - in some cases the headers were not visible in the exported report. This has been fixed. Headers will now be visible as expected. Note: the rows with 'summary' groupings have no headers. But the headers in the report will apply to all the 'data' within each grouping.
2) Formulas now supported in sharing portal reports: Previously reports in the sharing portal did not show the calculated totals and subtotals in summary reports. Now those summary figures are visible in the sharing portal (just like they are in SF). Additionally, custom formula fields added to a report, will now show up in reports in the sharing portal! Yay and Double Yay!
Summary reports are nice and easy to read in the sharing portal - but not as useful when exporting.
To minimize confusion when exporting summary reports -- limit the number of groupings you create. The grouped headings are exported -- but aren't useful when trying to deal with the exported data because they are just 'summaries' - and not actual data.
We recommend using tabular reports in the sharing portal for reports designed for exporting. (They are also searchable and sortable in the sharing portal so tabular reports have real advantages!)
Summary Reports and Matrix Reports are great for reading and viewing in the sharing portal, as they can show calculated results through summary totals and formulas. But they are kind of awkward for exporting, since they mix summary info and groupings with actual data.
In the Search Opportunity Filters, the picklist options often appeared in a random order. They did not reflect the order of the picklist values in the fields themselves in Salesforce. Now, whatever order your picklist fields are in Salesforce, will be reflected on the public site. You'll see this in filters such as "Organization To sServe" "Issues Areas to Address" (Skills" "Activity Type" etc.
The navigation (menu items) used in HOC public site have been improved to provide greater compatibility for users with visual disabilities who rely on screen readers to navigate websites. Additionally, system forms for login, advanced search, basic search, calendar, opportunity detail pages, search filters and options, partner signup, volunteer registration, and social networking have been made accessible to screen readers.
When you migrated from HOC 2 to HOC 3, any volunteers or partners logging in were able to log in with their original password. This made transitioning to HOC 3 pretty much transparent. We did this by preserving their previous password from their original Salesforce User records.
Starting with this release however, any volunteer or partner, who has not logged into the public site since you migrated to HOC 3, will find their previous password is no longer preserved. They will have to click on 'forgot password' and create a new password in order to log into the HOC 3 public site or sharing portal.
This should only affect those rare volunteer or partners who have not used the system in the many months since you migrated from HOC 2 to HOC 3, so we don't expect this to have any real impact. (If they haven't logged in in such a long time, they probably are unlikely to now). However - if you have a volunteer or partner who hasn't logged in to your site in a long time - and they find their password doesn't work, just tell them to click on the 'reset password' link. (We imagine most people will do this intuitively if they see their password doesn't work :-)
0 Comments
Add your comment