Sharing CiviCRM Use Cases

From DevSummit
Revision as of 22:11, 15 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Facilitated by Mark Libkuman, OpenFlows

Mark will discuss the situations in which OpenFlows has implemented CiviCRM, including at a public access TV station in New York City and as part of the 2010 US Social Forum. The session will be designed to invite others to share their use cases, and compare how they're applying CiviCRM in a number of nonprofit contexts.

Session Notes

Use Cases for CiviCRM Mark, OpenFlows Community Technology Labs Using civi for US Social Forum and Manhattan Neighborhood Network, public access station built them: 4 separate depts, built on Drupal, majority in Drupal, especially with workflow All the producers are in civicrm Profile is basic building block: set of fields attached to a contact custom data fields, like the neighborhood they live in ny, whether they have verified data Both goes to drupal and civi 2 of the depts which are going out into the public sphere, recruiting orgs to make shows. Object in system which is affiliate org, enter in civi. Define relationships btw contacts. Individual and organizational contacts Choose members for organizational contacts. Project is a show with episodes and airings. Want to track relationships between projects and contacts. Also based off the workflow in Drupal. Store projects both as contacts in civi and also as Drupal nodes. Goes against best practices of data architecture. Through Drupal hooks, when you save a project node, through civi API, create org contact, tie relationships btw org contacts in civi and producer contacts in civi. Every time you update project node, it updates the civi. The hole in the system is we didn’t allow projects to be updated on civi side. In 3.0 you have amazing hook system. Declare a function in drupal hook. Saving a form, define a function where every time a form gets saved on civi side, that action gets executed on Drupal side. Were there data consistency issues? Not yet. On Drupal side, you have computed fields, function to fetch data.

US Social forum: multiple Drupal sites, one has a civi instance associated with it. Public facing site, social networking site, registration site where user accounts created. Through OpenID, create account for the networking site, all registration goes through civi. Through Civi Event, create event, with ppl who can sign up for your event. Basically an online registration with payment processor, pricing fields/premiums. Use case: a family member can attach other member to same registration. Extending civi for organization register. Added fields to the profile, so individual contact created and through hook, creates organizational contact

Goals: Integration with Drupal Keeping configuration to a minimum. Make sure it works out of the box. Working with non-org ppl, data doesn’t have meaning outside of a discrete event. Selenium can be used for configuration, to flush out data periodically.

Civi can be run on shared hosting, but Dharma does not support. You get stuck at a release, its harder to customize, its harder to control who can access it.

VPS are cheaper than shared hosting. Civi’s limitations running on shared hosting. You’ll need a db, ability to create tables. How do you decide that civi or salsa or whatever is the right thing for you? Mission to open source tools Free. If you have a client site in trouble, you can clone it. With salsa, nominally licensed. Powerful, but requires geek. Permission system designed for multiple contributors, but not robust permission module like Drupal (without extension). Civi has well-documented API Domain access module allows for multiple Drupal accounts to share civi user account