July, 2017 Release Notes
This release features a number of improvements that make HandsOn Connect more compatible with HOC3 sites. Adjustments have been made to sharing rules, and internal logic has been changed to support a broader range of Salesforce configurations and the needs of International Customers.
As has been noted elsewhere in this forum - the current behavior of HandsOn Connect is to apply restrictions (such as minimum age, background check required) ONLY to Date and Time Specific - full sign up opportunities. The various 'express interest' opportunities DO NOT apply restrictions to expressing interest. This default behavior has come as a surprise to many HandsOn Connect users who assumed that restrictions were being applied to other opportunity types, and would prefer to have their instance configured to always apply restrictions.
It is now possible to control whether or not restrictions are applied to each Volunteer Opportunity Type. You can also easily make restrictions apply to ALL opportunity types. If you take no action at this time, the current settings will remain in effect.
Current settings for Applying Restrictions to Volunteer Opportunities:
- Date & Time Specific - Full Sign up ----> Apply Restrictions
- Date & Time Specific - Express Interest ----> Do Not Apply Restrictions
- Individually Scheduled - Express Interest with Schedule ----> Do Not Apply Restrictions
- Individually Scheduled - Express Interest Only ---> Do Not Apply Restrictions.
If you wish Restirctions to apply for ALL opportunity types:
Follow the simple Administrative speedup detailed in this article:
Doing this will make all opportunity types apply restrictions, and bypass the workflows described below that set the restriction settings for each opportunity type. If you apply the change to the default value for this field as described in the linked speedup, then there's no need to do anything to the workflows described below.
If you wish to have SOME opportunity types apply restrictions, and other NOT apply restrictions:
The current apply / do not apply settings for each opportunity type are controlled by the field updates applied to these four workflows found in Setup / Workflows:
- Apply Restrictions - Expresss Interest
- Apply Restrictions - Express Interest Only
- Apply Restrictions - Express Interest with Schedule
- Apply Regisrictions - Sign Up
If you view any of these workflows you'll see they are each assigned to one of two Immediate workflow actions:
Field Update: Do Not Apply Restrictions
Field Update: Apply Restrictions
If you wish to change the current restriction behavior of any of the opportunity types (but not all of them as described in the comment above), then simply EDIT the workflow action associated with the workflow rule, to either Field Update - Apply Restrictions, or FIeld Update - Do Not Apply Restrictions, as desired.
Want to make changes to the default behavior regarding restrictions, but nervous about following the steps above? Come to any lab session and we'll quickly take care of this for you and show you how :-)
The presence of a 'username' in a contact record generally indicates that a person has 'log in access' to the public site or the sharing portal.
The mechanism by which a change in email address automatically updates the username has always kept a person's username in synch with their email address. However, in some instances of Salesforce, there were contact records with email addresses who had not yet registered or been given access, and therefore had no username.
Because of this synching mechanism, if one changed the existing email address of a contact in SF who did not have a username, usernames were being ADDED to these contacts, which then prevented that contact from registering via the public site. (They'd get a message saying that the username already existed!)
This issue has been corrected - and now, if a contact does not already have a username and the email is updated in a Salesforce Contact Record -- a username will not be created for them.
There were reports that if you made an organization an active partner, and then changed their status back to pending or inactive, and then tried to update to active partner again an error resulted. This has been fixed.
Each night at midnight - an apex job is run to review all existing occurences and update the posting status so that the posting status is accurate based on the current date. There were reports were this was not happening in all organizations.
The culprit turns out to be 'bad data'. Having occurrences that are missing required fields (such as "Volunteer Opportunity" can cause a batch job like to fail.
We've updated the batch job to be more tolerant of bad data and to not attempt to update occurrences that are missing the volunteer opportunity.
That said - we urge all admins to monitor their occurrences and make sure that required fields are present in all occurrences. (This sort of 'bad data' occurs when users delete a record that is required for occurrences. This could be the result of deleted volunteer opportunities or locations. Our advice: Don't Delete Records! (or at least - don't delete them if they are used in any related records. Never delete a record that has 'related records".
Want to make sure your data is 'clean'? Run the report "Missing Informatioin-Occ' found in your HOC Support Folder. It will show you any occurrences that are missing either a location, a volunteer opportunity, a start date or end date, status, or maximum attendance. All these fields are required in an occurrence.
(Note: Except for 'location' - which is NOT required if its an Individually Scheduled, Express Interest Only opportunity.)
Run the report and clean up (or delete) the offending occurrences. (Make sure they don't have any connections before you delete them though!)
Creating location records have always required a value in the "State" field. However, since not all International customers use states the way they are used in the United States - the requirement for a value in this field has been removed. It's now possible to create a location that does not include a state. (Nonetheless, we recommend that for U.S. Customers you always DO put in a value for the state).
Good news for those of you using the check-in kiosk and allowing guests to check in. If you have volunteers in pending status - their connection will now be properly checked-in!
The new HOC__EditiionSource__c field has been added to the workflow "Update Attendance Status" - to identify that the connection is being updated through the check-in kiosk. When this is the case:
- The status of the connection is updated from pending to confirmed
- The attendance status is updated to Attended and Hours Verified -- and the hours are now automatically calculated!
0 Comments
Add your comment