Membership statuses and approval workflow

[Angharad]

Hello - I'm new here, and I apologize if I am missing something that should be obvious, but try as I might I cannot find an answer to this question.

I am trying to properly configure CiviCRM for an individual member-based association. We have one-year memberships and the dues are 80 euros per year. All new memberships have to be approved.

Therefore, our ideal workflow would be something like this:

1) Person applies for membership/ new membership record is created and status is automatically set to "Pending" (or "awaiting approval").

2) Membership application is reviewed by admin and either approved or rejected. If approved, there should be a way for admin to somehow change the status to "approved - payment pending," or something like that, without using override.

3) Once the dues are paid, the status should automatically become "current - in good standing," or something like that.

I would like to be able to accomplish the above without having to do manual overrides of member status, as these are prone to human error.

I was under the impression from reading the "CiviCRM user and administrator Guide" that there would be a way to have an approval workflow for memberships, so that the status would initially be "Pending" and then would be changed to "New" after being approved.

From book.civicrm.org/user/archive/4-4.1/membership/what-you-need-to-know:

The default set of status options provided by CiviMember is:
    Pending: someone who has requested membership but has not paid, or is awaiting approval.
    New: payment has arrived, or membership has been approved.

However, I do not see a way to configure it so that the memberships can be "approved."

I thought maybe there would be a way to address the issue by using the "pay later" notion. I.e.,

1) Individual applies and automatically gets initial status "awaiting approval"

2) When individual is approved, admin enters a payment with payment status "pay later," which changes membership status to "pending"

3) When payment is completed, membership status is automatically updated to "current"

However, that last step doesn't work, because when the payment gets completed the membership status just goes back to "awaiting approval," since it's weighted lowest among the membership statuses.

I think it might be helpful for me to know more about how the special "pending" membership status links to the payment of membership dues, but I cannot find much detail about that in the documentation.

I saw some discussion about related issues in the forum from back in 2009 and 2010, but I haven't been able to find anything more recent. If anyone could point me in the right direction, I would appreciate it.

[John Q. Public]

I've run into this as well and not been able to find how to implement an approval based workflow for memberships. It is odd in that the manual references approvals and the application has membership states that would seem to support it, but there doesn't seem to be any way to actually do it. Any help would be very welcomed -- thank you

[CiviTeacher.com]

Most people envision a button an administrator would press to "approve this member", at which time the member is granted privileges instantly.  This is not my understanding of the CiviCRM system.

Rather, membership approval with CiviCRM is expressed in one of two ways.

The first is more like a waiting period.

Let's establish some basics.  Membership 'benefits' that a member gets (upon approval) are usually expressed in one of two forms:  1) access to 'member content' or 2) display of member data a public 'directory' or 'listing'

In both these cases a 'waiting period' can work by tweaking the 'new' membership status rule in conjunction with CiviCRM Member > Role Sync or Drupal Views.  If an administrator has not cancelled or deleted a membership prior to the end of the waiting period, the benefits 1) and 2) will begin.   The waiting period could be 1 day, 2 days, or 7 days, or any number of days really, you decide.

The second is more if you require a more 'hands on' approach then you will want to use groups like this.

If a member fills out an application form, configure the advanced settings of a profile used in the form to 'add them to a group'.   This group could be called 'pending members'.   Anyone in this group is restricted via Drupal roles or Drupal views from enjoying the benefits of the membership.  The admin must remove them from the group 'pending members' for the membership benefits to begin.