Volunteer-run organizations pose some extra thought burdens upon the SF NPE user.  Salesforce is all about hierarchical control — not that there’s anything wrong with that in the contexts where it is appropriate.  But when peer volunteers who are all of equal status have to collaborate, it gets a little bit trickier.  We want a second set of eyes to look at things — but it doesn’t much matter whose eyes they are.

We run basically two types of events:

• Cocktail Socials at fancy hotels
• Professional Development Programming (Professor Lectures; Alum Expertise Panels; Career Workshops; Joint Events with other MBA clubs)

Cocktail socials are easy:  pick a date and a venue and about a week’s advance notice (though results are better with greater lead time).  A few simple fields in EventBrite and through the  magic of Zapier, boom:  Facebook, LinkedIn and WordPress are all on, as it were, the same page.  Then Salesforce and MailChimp effectuate, as it were, the cattle call.  Nice and simple.

The other programming spans a wide range of effort and collaboration:

• identifying subject matter experts for programming guidance
• identifying panelists to participate
  • these can be in the context of self-generated (i.e. our club-only programming, which is easier) but often we collaborate with our peer clubs, extending complexity and decision cycles (we are, after all, volunteers)
• identifying a venue (ideally donated, failing that, rented)
• food and drink
• budgeting & expense tracking
• publicity, registration, reception

The scheduling constraints are, as you can imagine, not insubstantial.

So, I created three record types for the Event Force Event object .

Amusing Aside.  Humans are not well equipped to differentiate between Event Force Events and Salesforce Activity (Task/Events) when looking at them in the context of  API-populated drop-down menu: two five-letter words, spelled the same.  And much as there is magic in the point and click admin model, reloading after a mistaken choice always seems to set one back so very far.  But that’s a separate issue.

Aside aside, back to  EF Event and their three Record Types

• Event Idea
• Simple Happy Hour
• Complex Programming

Any volunteer is welcome to put an event idea in the hopper. A workflow distributes an email advising the volunteers to take a look – encouraging discussion on chatter and a formal look on the next  “board” meeting.  With finite bandwidth, an idea can stay in the hopper for a while; they can also be voted down and then the Aborted? checkbox gets a yes.  But more fun is when we decide to go ahead with an Event Idea.  For checks and balances’ sake, a volunteer initiates an approval process, with the auto-generated schema you see below.

Upon approval, the EF Event Record Type changes, and Event Idea becomes Complex Programming, with related lists for subject matter experts and for venues.  The status converts from null to Active Planning, and ideally moves towards Finalized and then to Published.  Though on occasion, not everything is meant to be, and we do have a value of Aborted in the picklist.  So my next task is to develop some objects and workflows to support marketing collateral development and its publishing to EventBrite, WordPress, Facebook Page, LinkedIn Page (& for good measure, Groups) plus newsletter planning through MailChimp & Salesforce.

By contrast, Cocktail Socials (aka Happy Hours) are relatively spontaneous.  That’s a non-approval-based process (though there is an approval on the content elements to be put into the promotional materials).  Select your date & venue,  put that info into EventBrite and watch the cross-population begin.

More about standardizing and scaling our collaboration systems soon.

Thanks for your time.