Public Offers and Spontaneous Volunteering
Overview
To support recovery operations, the Crisisworks offers register supports volunteering via and a public registration form.
Functionality
The system has the following functionality.
A public form allows members of the public to register their offers of assistance
Chained lookup-driven category and sub-category fields
Workflow to allow offer administrators to verify and approve/reject the offer
Search support to be able to find offers matching certain criteria.
Advice on limitations and known issues for users
For offerers with multiple offers, multiple contact records will be created
Multiple public offer events are not currently supported
There is no way currently for the offerer to return and update their offer record
The offers data grid does not currently display the category, sub-category, or other information.
Roadmap
Beyond this release, the following roadmap is being considered. Please get in touch with Datalink to voice your opinion.
Volunteering Form
The volunteering form is a schema of the offers register, having a public and administrative view.
Public view
The public volunteering form has the following additions.
It uses the
volunteer
schema within the Offer register, and thevolunteer
schema within the Contact register.The admin sidebar is hidden for public submissions, and replaced by helper text.
The submitting event is automatically selected to be the first event found containing the public user on duty in the Public Offers position.
If no events have the Public Offers position allocated, the form loads with a message saying that offers are not currently being accepted.
The public form is accessible via the URL segment /register/public-item/new/register/offer
Administrative view
The workflow, classification and advanced sidebars are visible to administrators.
As the form has a 1-1 relationship between offerers and offers, a checkbox for “I have registered before” will allow administrators to manually link a single offerer to multiple offers.
Form conditional and special logic
The following special functions are on the form:
The sub-category field is chained to the category field
The “Accommodation” category exposes additional fields about the style and size of accommodation.
All the categories that relate to labour services (trade, council support, etc) expose questions relating to human service provision (is accommodation required, prior experience, qualifications, etc). This uses a consistent data conditional rule that checks for the category having a prefix of
svc-
.The event is hidden and set automatically to the first open event containing the public offer system.
Administrative functionality
Setting up events to accept public offers
Create an event with both an
offer
andcontact
registerAdd your administrative position to the event
Add the
Public Offer User
position to the event.Select “automatically go on duty to this event” to go on duty to this newly formed event
Add the Public User to the event to activate the public form
Go to the user data grid,
search for Public User,
click Manage Duties for User, and
put them on duty for the event in the Public Offer position.
Removing public access
To remove public access, remove the Public Offer position from the event.
Managing Categories
The category system uses two chained lookups.
“Offer: Category” is the main category
“Offer: Sub Category” is the chained sub-category
To manage these lookups:
Click Administration > Settings
Click Lookups
Click the search icon at the top of the left-hand sidebar
Select either “Offer: Category” or “Offer: Sub Category” from the category list
Click Filter
Category lookup values
The following conventions are required for the form to work properly:
Values must be all lowercase with no spaces. Hyphens are okay. e.g.
council-services
is good;Council Services
is bad.The only non-alphanumeric character that should be used is the hyphen (
-
). Especially keep away from slash (/
).
Chaining sub-categories to categories
The sub-category lookup values should follow these conventions to work properly:
Values must be all lowercase with no spaces.
Values are prefixed with the category value and a slash. For example, to add a sub-category under the
council-services
example category above, you can addcouncil-services/waste
as a sub-category value. This would then appear under that category when it is selected.
Making categories expose labour service fields
Some of the form fields on the offer form relate to offers for labour services. At the time of writing, these are:
“I will require accommodation” checkbox
“Qualifications” textarea
“Prior Recovery Experience” textbox
Others may be added in future.
To activate these fields, the category value should be prefixed with svc-
. For example, the category value svc-council-ops
is used for the Council Support Services category.
Managing Work Areas
The public offer form has a question on areas that you’d be prepared to help. This is controlled via a lookup called “Offer: Work Areas”.
Managing the public help text
The help text on the public sidebar is controlled via a library wiki page, stored in the Global Workspace.
The wiki page is called “Public Offer Help Text”, and is a special type called “System Text”. This can be accessed via a counter in the wiki sidebar called “System Text”.
This type is aligned with a system ID that connects back to the form, and anything you add into the rich text area of this page will display on the form.
A special feature in the “Advanced” field set allows users to lock the page against accidental status changes or changes to other metadata.
Workflow
The offers register provides a workflow for approval (or rejection) of new public offers.
Expiry workflow will expire the offer if a validation date is set
Bulk actions will allow bulk changes to the status, assignment and tagging of offers
Search will allow deep search across all fields of the offer, along with quick searches for key fields such as status, category.