Constituents who are Organizations

Yes, this is functionality I need, and the spec outline seems right on target. Some additional ways functionality along these lines could be extended:

1) Allow permissioned users to manage/edit other individual records for the organization they are an employee of. Thus one authorized employee could bear responsibility for managing contact data for all the organization's employees on file.

2) Mimic "use household address" behavior for employee/employer. This option should be available in the frontend signup forms as outlined above, as well as in the backend admin.

3) Tangential to this discussion -- extend search capabilities to allow cross-contact type searching. For example, find all Individuals where their Organization tag = xyz.

4) Some of this functionality may spill over into the multi-person event registration discussion. Maybe someone needs to be a permissioned user in order to register on behalf of other people? I think this control would need to be optional, as in many circumstances it would be counterproductive to require someone to be permissioned BEFORE they complete the registration form.

5) Managing permissioning seems to be the trick with this. For things like a contribution by an organization, or a new membership signup, I could see simply giving the user the option of contributing/joining on behalf of the organization. But when it comes to editing an existing organizational record, I would think the admins would want to have some control over who is permissioned to act on behalf of the org in this way.

6) With membership signups -- one thing that might eliminate the need for the "I'm joining on behalf of my organization" option is adding the option to assign membership types to contact types. Thus the "Gold Membership" is DEFINED as an organization level membership, whereas "Associate Membership" is defined as an individual-based membership. Some categories of membership may be ambiguous, in which case the option as described above would be necessary. But for those that are not ambiguous, the option may not be necessary. If I go online and join for a membership category connected to orgs, it should automatically determine that and insert the membership record accordingly. Defining these options and structuring them logically could be tricky.

-Brian

Especially self-service organization updates.

We also serve both organizations and individuals. Organizations have a primary and secondary contact who are (usually) Drupal users and responsible for their organization's profile information, most of which is publicly viewable. Then each org. can also have an unlimited number of staff contacts, CRM records entered through a short profile form that establishes the employer-employee relationship and adds the record to a group for our main mailing list. The primary and secondary contact would benefit from access to edit their org's info - access for staff contacts is not important.

Also useful would be to allow individuals to submit information on behalf of their organization. For example, information about a current project that could be linked to from their org's profile.

The approach you've mapped out seems to hit the mark. That would be an excellent addition!

Taking the use cases a bit further to handle the one-to-many relationship from an organization to individuals:

• Adding multiple employees - Janet purchases a membership for "Art for Kids". Because she is the first to register the organization she acquires administrator privileges for the organization record. This organization membership is of a type that confers memberships to all employees, so Janet wants to register co-workers Bob and Anne. She views the "Contact Dashboard" of "Art for Kids", and clicks the link "Add employees". Janet enters email addresses of her colleagues. Bob already has a user account so his record is updated with a relationship to Arts for Kits (and he maybe receives an email asking him to click a link to confirm). Anne's email address is not found in the database so a new account is created for her and a new user confirmation email is sent to her. When she completes registration then she has an account with an employee relationship and membership status.
• Managing organization relationships - From the "Arts for Kits" Contact Dashboard, Janet, as the permissioned administrator, could add (as above) and remove employee relationships. Bob and Ann would both see their organization relationships on their Contact Dashboard and would have the permission to just remove their employee relationship with "Arts for Kids".

I used a similar technique for bioneers. When a user submits an membership purchase for an organization I've got a drupal form that collects the organization details. I then create the org and relationship on submit. I like the ideas about relationship perms too. At Advomatic we have an issue where sometimes org details need to be changed, but users don't have access to their organization to do the change themselves.

--
Dave Hansen-Lange
Web Developer
Advomatic LLC
http://advomatic.com
Hong Kong office

Guys, this is almost exactly what is required for the organisation I'm involved with

We offer individual memberships and we also offer:

1) Corporate memberships
2) Academic Faculty memberships.

The key thing about the corporate/academic faculty memberships is that they are effectively 'buckets' of memberships (10, 20, 30, 50) that an organisation can sign up for and then distribute to their employees/faculty members. We have a an 'admin contact' within the member organisation but each person that signs up under the 'corporate' banner is treated as an individual as regards benefits etc. This is similar to the "permissioned employee" relationship you identify above.

The 'Admin' person can then add/remove members (create employee/employer links between individuals and the organisation effectively) up to the limit of their 'bucket' during the course of the year for no additional charges (if a member is removed from a corporate we then chase them to renew as an individual at a discounted rate. Currently this is managed by email between corporate members and our admin team. No one has exceeded their 'bucket' yet so we don't know how that would be handled (probably an upgrade to the next level at a discount...)

Also some 'super corporates' e.g. Partner organisations might have an unlimited 'bucket' size but would otherwise be managed the same.

If we could

a) allow the corporate sign up on-line
b) allow 'super-user' members in a Corporate membership 'bucket' to administer their membership make-up directly (exposing some admin functions to this 'super-user' just around this process area
c) control the number of members in any given 'bucket' and trigger actions or reports for follow up if a corporate exceeds their 'bucket' limit in a given period.

then this would be 100% what we require. If it helps I can map out the logical data model we are operating and some of our current and planned processes around this type of membership.

In the (completely theoretical) event than a user completely screws the record of his organisation, it would be great to have an option:
1) to automatically flag "tainted/to be reviewed" each modified organisation.
2) for an admin to revert to the previous version before the user modified it.

(this is a generic feature that could be as useful on modification from a civicrm user than from a user from the organisation self-serviced)

X+

I have been working and hacking away to accomplish this kind of scenario. I'm using Joomla so there is a combination of Joomla front-end components and just using the relationships as permissions in a sense. I am hoping you guys get a boot camp set up this summer that I can attend and I'd be happy to show you my (probably not very elegant) approach.