2020 June Sprint Notes

Project Team

• Attending: Evan Ponter, Reede Stockton, James Browne, Kai Williams (team lead), Mel Brockley, Collin Zimmerman, Chris Pifer

Project Details

• NPSP Membership out of the box requires a lot of customization to meet organization’s specific use case.
  • Membership isn’t always a fundraising tool.
  • Some organizations use membership in a different way: individual and group/organization membership
  • It is not easy to do renewals.
• Example: Hostel International (Evan’s organization)
  • having membership gains you access to benefits/discounts, include in marketing messages, etc.
  • Physical card, with expiration date.
  • Using opportunities to represent a membership purchase. OLI/Product2 are used for membership items purchased.
  • Membership record (Custom object), able to associate the membership to the contact or account.
  • Created a membership type to email/online purchase
  • purchase, expires, tracking of physical items
  • Retain membership number (e.g. member 12345)
  • Workflow rule to send an email to the individual based on a field getting modified.
  • Initial purchasing is completed from FormAssembly
  • Renewals
    • Sent through Marketing Cloud
    • Three emails before someone’s membership expires.
    • Each month has a dedicated SFDC campaign. Adds individuals to a month when they expire.
    • Uses MAS to populate contacts into the correct month’s campaign.
    • Currently don’t have auto-renewals
    • Set renewal date to start the day after the end membership
• Example: International Wildlife Rehabilitation Council (Kai’s organization)
  • Has several checkboxes to indicate the type of membership (e.g. auto renewal, include in directory)
  • Delivers physical membership card, created manually
  • Supporting other NGOs to share information/education. Membership benefit is discounted learning.
• Previous discussion is custom object vs opportunity object.

Evaluate custom object against standard opportunity object

Review V3 of the Membership / Sponsorship Schema with Benefits PDF

• Custom objects
  • Pros
    • Allows for quick free memberships.
    • Allows for opportunity to exist only for transaction (exchange of money).
    • Allow for easy record type separation of memberships
    • Allows for a single purchase to include multiple memberships (e.g. corporation purchases a membership for 5 employees)
  • Cons
    • Another object/record
    • Requires custom architecture for multiple individuals to a membership.
• Standard/Opportunity objects
  • Pros
    • One less object to maintain (FSL, storage, etc.)
    • NPSP solutions already exists (e.g.rollups, levels, etc.)
  • Cons
    • Confusion membership with donations, purchases, etc. Other transactions
    • OCRs can’t have external IDs
    • Creates an empty $0 opportunity for free memberships
    • How are memberships bundled
• Orders standard object
  • Pros
    • Functions like opportunity but is its own object.
    • Has native “bill to contact” and “Ship to Contact”
  • Cons
    • Might confuse “Orders” and require renaming to “membership”
    • Doesn’t support multiple payments against a membership.
    • Creates the same frustration as with Opportunities (an org could use orders natively)

Team chooses, custom object.

Use cases trying to solve

• basic
• middle architecture
• open architecture for an ISV

[Image: Screen Shot 2020-03-31 at 4.54.03 PM.png]

Steps for tomorrow

• Recreate the ERD
• Add a Git project for building
• Have clear documentation for path to choose.

Outstanding questions

• What about upgrades (e.g. you purchase a ticket and decide to upgrade to a membership)
  • we need the ability to discount
  • we need a way to show both purchases (ticket and later upgrade)
• How do you renew
• What happens if someone’s membership is purchased early
• What about gift memberships

Random thoughts

• The ability to specify members automatically

April 1

Requirements

We've reviwed the list of requirements and confirmed that the model fits. Notes below

• Track retention, renewal and reacquire
  • "Benefits" object can encompass membership as well as sponsorship. And provides a high-level overview of allocated benefits and usage of those benefits
• automate labeling of membership opps as new, renewal, reacquire
  • Could be a future project
• Individual memberships
  • Tracked w/ Membership RT Benefits object + contact benefit role junction object
• Dual & Household memberships
  • Supported using one Benefits object and a Contact Benefit Role object for each "member" or recipient
• Multiple Contacts attached to a membership, not necessarily tied to a Account
  • Supported via Contact benefit role; detached from Account
• benefits/or Membership can be assigned to specific or additional contacts - relevant for Organizational membership that grants benefits to a specific number of members
  • Supported because Benefits don't flow down to Contacts via Account; Affiliations could be leveraged to automate if desired
• Memberships without payment, eg, gift memberships & subscriptions
  • Benefit does not need to be linked to an Opportunity
• Free memberships
  • see above
• Membership levels & products
  • Retains current flexiblity to use either a membership picklist on Benefit (rather than Opportunity) or use various record types or Products to track this
• Overlapping membership levels, especially re: discounted levels like Senior or Student
  • This is a business process decision to be made by the organization; could assign additional Benefit Items based on org business process. Example: senior + student discount; can be assigned additional Benefits Item; Benefits object could have a senior/student level picklist or simply choose one over the other, could use discouting in Opportunity Products.
• Personal Benefit/non-tax deductible amount
  • Flexiblity to use either Opportunity or Opportunity Product for this
• Multiple memberships per contact
  • Supported!
• acknowledgements & receipting
  • Payment acknowledgement/receiting continutes to be handled on the opporutnity, if desired Benefits emails could be created or automated
• automate renewal creation
  • Optional based on business processes (could automate this in many ways internally); not part of the initial package
• automate renewal reminders
  • See above
• tying benefits to specific events, eg, seats, ads
  • Have flexiblity to connect
  • Could create a lookup relationship from benefit to campaign
• marking memberships as lapsed
  • End date field on Benefits object
• grace period
  • Defined by business process/future requirement
• multi-year memberships
  • Defined by business process/future requirement
• membership # associated with Contact(s)
  • Optional business process, could live on Contact or custom object
• membership card
  • Optional businss process
• suspending memberships
  • Could suspend either at Benefits level or at Benefit Contact Role - could automate using Affiliation status for business
• organizational memberships
  • Supported
• periodic/recurring payments for memberships
  • Payments are separate from benefits
• suspension of membership if recurring payment missed
  • Optional; could be automated/future
• Communities compatibility/automation
  • Supports all licenses
• differentiate between membership benefit entitlements and actual receipt of benefits
  • Optional "benefits use" object could be built or simply use picklist on benefit item
• track if member declines benefits - relates to tax-deductibility as well
  • Could be supported according to business processes
• benefits over longer period of time, including over multiple events
  • Supported

Sprint 2020 Virtual Sprint (may relate to this Sprint, but if not it relates to the March 2020 Sprint)

• Created v4 schema
  • benefits catalogue/used objects could fit into schema but not mapped out as out of scope for this Sprint
• Implemented v4 schema in scratch org with custom fields and relationships
• Discussed and solidified decisions made in prior groups regarding membership, ensuring flexibilitiy for a range of use cases