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.

In the Volunteer Overview page of the public site, there is a link in the Volunteer History section to give Feedback.  Some people prefer not to allow feedback through this link, and/or have created an alternate form for gathering feedback.

In this release, the CMS now allows you additional configuration options for the Forms / System Forms / Volunteer Account Overview Page. Options allow you to:

• Not display the feedback link at all, or
• Display the link, but have it redirect to a different page (rather than the standard feedback pop-up)

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.

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.

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.

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:

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:

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.