HOC 3.0.8.16 Release (Nov 14, 2019)

This release includes behind the scenes improvements to protect HOC Public Sites from malicious attacks and improve security, improvements in the synching of data between HOC forms and Salesforce,

More Granular Control over Self-Reporting methods (HOC3-9967)

HandsOn Connect has always had two ways Volunteers could self-report hours:  "Self-Report Hours"  and "Record Hours" both of which were referred to as 'self-reporting"

  1. Self-Report Hours:  The Self-Reporting navigation item, that allows volunteers to enter hours served for Opportunities with partners or outside organizations that weren't posted, managed opportunities.  

Note: "Self-Reporting" via this navigation item has multiple configurations available.  Please see this article for the possible options available for 'self-reporting".     https://training.handsonconnect.org/m/3428/l/1001662-advanced-self-reporting-configuration-options

2. Report Hours:  On the Account Overview page, using the "Report Hours" link to self-report hours that had not been verified yet by the Opportunity Supervisor for existing opportunities.  

While it's been possible for HOC to be configured with Self-Reporting either 'On" or "Off" its not been possible to have only one or the other of these types of Self-Reporting.  You either enabled both or neither.

Now, with this release, its possible for the support staff to configure your instance of HOC with one or the other, or both or none of these 'self reporting' options.

If you wish to have one available, but not the other, please open a support ticket.

Going forward we'll refer to method 1 as "Self-Reporting" and method 2 as "Report Hours".   So if you wish to request please turn off "Report Hours" but leave "Self-Reporting" active -- we can leave one on, but turn the other off!  Open a support ticket if you wish to change your prior self-reporting configuration.

Beta:  New ARS Type:  Basic Log in. (HOC3-10221)

The ARS (advanced registration system) previously allowed customizations of the experience during Volunteer Registration, Partner Registration, or could create workflows and forms for Opportunity Sign-Up.

With this release, the ARS also introduces a powerful new feature: The ability to create workflows based on the User Log-In Experience

In a nutshell:  This is a workflow that runs when a user logs into the public site.  It looks up info from the contact record of the logging in person, and can be used to control what happens during the login process.

By default, a volunteer logging in is taken to the Account Overview page.  Using the basic log in ARS, you could opt to take the logged in user to. a different page instead.  Or ask additional questions or display additional information during the login process.

Notes:

  1. This is a beta feature and therefore there may be limitations on what you can do using this feature.  Please report any bugs or issues to support if you opt to use this feature.
  2. If your site has SSO active you can not create an ARS login workflow
  3. This feature only works when using the standard Log-In Widget at the top right of the page.  The Log In Workflow does not work if a non-logged user signs up for a volunteer opportunity and is prompted that they must register or log-in to proceed.   (So there are ways for a user to login without executing the ARS Log In workflow).
  4. Only one Log In workflow can be active at a time:

 

A log in Workflow is created from the CMS Advanced Registration Menu and is called "Basic Log In".   Choose 'add workflow' to create a log in workflow.

Give the workflow a name, and designate whether or not it is active.  You can then create pages and branch logic in the manner used for another ARS workflows:

Whether or not you choose to add additional pages or forms to the log-in process - you can use branch logic to specify where to direct the user after the log-in is completed.   By default you go to Volunteer Account Overview - but you can set any specific URL as to the page the user is sent after log-in is complete. You can also set conditions based on fields from the contact record (through a form), so that a contact with certain characteristics is sent to one page, and another contact is sent to a different page.

The ARS is a powerful and complex tool.  Because we are continually adding new options there is not extensive documentation on all of its features and use cases.  For assistance on working with the ARS, we recommend you come to one of our daily labs and ask for assistance when you need specialized training.

ARS/Forms Improvement:  Hidden fields are now able to write to any field type (HOC3-6879)

Hidden Fields in forms and ARS are often used to pass a record id or record type id to SF.  Its now possible to use hidden fields to write to any field type, including lookups.

ARS / Forms Improvement:  Ability to hide submit or next button (HOC3-7161)

The final option on every form, and on every page of the ARS is a 'submit' button.   There may be circumstances in which, if certain logical criteria aren't met, you do not want the user to be able to submit the form (or go to the next page of the workflow).   To make this possible, there is now branch logic available for the submit button.

By default the button is always shown, but you can set conditions for showing the button or for hiding the button from the form:

In a form - this affects the 'submit' button.

In an ARS workflow - this logic affects the "Next" button on the page you're working on in the workflow, or the "Finish" button on the last page of the workflow.

If no logic is applied - the submit, next, or Finish button will always be displayed by default.

More Granular Control over Salesforce Mapping in Forms: (HOC3-10164)

When mapping data to a Salesforce field, there is now granular control over whether you do or don't wish to Save data from the form to Salesforce and whether you do or don't populate existing data that exists in the field in Salesforce.  By default, mapped fields DO populate from existing SF data and overwrite that data with info submitted in the form. However now you can surpress either of those behaviors through two new checkboxes in the mapping section:

 

Bug Fix:  Ability to drag fields in forms (HOC3-10194)

The ability to drag a field type directly onto a form had stopped working. This has been fixed.  Now you can drag a field type directly to a location on a form again.

0 Comments

Add your comment

E-Mail me when someone replies to this comment