The way the permissions work now if I want to give the front desk person the ability to see if someone is a member I have to give them access to all the companies financial data, including financial reports.

This one issue is going to get Wild Apricot replaced in our organization.

At least there has to be a feature to lock old months records editing. Currently everything is open and donation manager can go change any record or payment without any kind of restriction in wild Apricot system.

Donation managers are human, they can make mistakes but application should have enough control to avoid such situations.

We have membership/donations managers working from multiple locations, some old donations records were modified by users. It was really hard to track who modified which receipts as our balances of previous months were out of reconciliation.

Finance Dept. raised serious concerns about our selection of membership management solution as Wild Apricot as there was no option to limit old entries modification.

It’s a mandatory feature to have option to restrict membership manager and donations Managers not to edit old payments or donations in current application.

Kindly consider this post as high priority feature request.

Absolutely agree! I had someone with full administrative rights go in and monkey around with a web page. Now I have to fix it!

Page and feature (action button) level access permissions should be available

I just need my donation managers to be able to edit existing contact info. They can put in NEW contacts, but they can't change info for existing contacts, which is a real problem. The donation managers see checks, etc. and have contact info.

A few thoughts about delegated administrative roles:

Within each general administrative role there are specific features which involve viewing/creating/editing/deleting data on the system. Within that data I see a distinction between data that is common service data (contacts data, membership data, system settings, financial settings, system email templates) and other data, which I will refer to as content data.

Common service data would include all data that would not qualify as a specific communication or service by the organization.

Content data is the complement of common service data: it includes communicating and providing the services offered by the organization. Content data would include web pages, email blasts, forums, donations, blog entries, RSS feeds, the forthcoming store, and events.

Each feature in an administrative role allows for viewing/creating/editing/deleting data. A feature might be a single field or function (for example, a visibility setting) or a set of fields or functions (for examples, the details of an event or the details of an event registration type). Viewing the data might be a default that comes with the role, but there might be some exceptions.

This brings up what I call scope: the area of viewing and control for a (delegated) role or feature.

In the case of common service data, the scope would be limited to the categories defined within the role’s area of responsibility. For example, the scope of a delegated finance manager could limited to accounts receivable or other types of reports. A delegated group manager might be prevented from creating new groups but could edit members within the selected groups under the control of that manager.

Content data would have an additional parameter to scope: to limit the administrator’s ability to view/create/edit/delete content generated by that administrator or by other administrators. For example, a donation drive, web page, email manager, forum manager, or an event manager could be limited to viewing, creating, editing, and deleting

• just the content generated by that manager personally,
• the content generated by managers within a membership level,
• the content generated by the managers within a group,
• or have full access to all content within that role.

With such granularity of permissions and a few tweaks to the existing feature sets, it would be possible to create implicit simple workflows for organization content data without having to program them in. To provide an implicit workflow to such editing, each set of data (an event, a donation drive, a web page, a forum category/forum area/forum thread, an email blast) would have a view restriction feature that could be switched between Admin, Restricted (to groups or membership levels), or Public. For example, by restricting a delegated administrator’s content to Admin only visibility means that some other administrator, who could see and edit the content, would have to authorize the set of data for a higher level of visibility. Similarly, restricting the visibility of that administrator’s content to the members of a group would allow peer review by that group (some of whom might not be administrators) before the content is made visible to full sets of members or to the public.

Implicit in such a scheme is that there always exists somewhere at least one administrator with full access to the entire administrator role. Also implicit is that the current number limits on administrators would not exist. Allocating delegated administrators could be limited to administrators who have been granted full access to a role or to full system level administrators.

For example, a full donations manager could delegate to a system user the ability to create and manage a donation drive. In setting up that drive the now delegated donation manager could be given access to a limited set of web pages at start to set up the donation. After viewing and removing the visibility restrictions on the new drive’s web page and donation settings, the full donation manager could give the delegated donation manager access to specific saved searches for sending out email blasts, as well view/edit access to the financial record keeping for that drive. Here I used donations as an example of how delegated roles might work; our primary interest is in events. In our case we have a need for an events manager role to be delegated down to the level of the event organizer, who in our case could be any or every member of our organization.

Delegating administrative roles empowers the membership, allowing them to generate the content that best serves to promote the organization. Empowering the members to self-organize their administration and the creation of content actually becomes a new service (content, if you will) that the organization can offer to its members. To borrow from a Canadian of note, the Wild Apricot medium itself would become the massage.

Custom Administrator Role user permissions are very important need for organizations have multiple administrators or bundle administrators to manage membership data.

Permissions for each feature set would be ideal as in already present other applications, like

- Insert or Add new data
- Change Data or Edit
- Delete data
- View report
- View Audit Log of any entry
- Export Data
these permissions should be allowed to configured for each screen like Contacts, Members, Donation, Payment, Invoices, Membership Levels for through security access control mechanism.

Very important for us. We have volunteers doing certain management tasks. Some of them are not particularly tech savy. The existing roles would be giving them the ability to do a lot of damage.

Event administrators should be able to see and manage event financial data but not other financial data

This feature should be added for better control, it's an important requirement for our organization and most demanded missing feature during implementation of project.

Add/Edit/Delete permissions for each screen like Members, Donation, Payment, Invoices etc. are required for proper user access permissions management as current roles have full permissions which becomes an issue, it's not easy to rely on Audit Log report to capture who deleted which record every time when you have multiple administrator (Donations Manager / Membership Manager role) users.

I'd like an admin level of "event assistant", someone who can check people in, but cannot send out emails or change event details.

In my organization, we want donation only visible to Donation Manager and not to other Managers.

Administrative Roles Update. Separation by Officer designation.
Secretary- Member Management. Treasurer- Financial Management - the ability to manage member invoices and payments but not change the members, membership types and information. Event- Manager- For specific events only.

I also agree that the existing limits on the number of administrators are too few in number but, if this number were increased, too many admins would have too much power. One question that I will ask, and for which in fairness I don’t expect Wild Apricot to answer publicly, is does Wild Apricot actually need a limit on the number of administrators when there already exists another parameter, the number of contacts, for moving an account up to the next pricing tier?

For an organization to grow organically it needs to rely upon its members’ contributions from below and that means empowering the members with some of the powers currently held by system administrators. The lesser powers could be assigned to individuals, to groups, or to membership levels. In our case we would want essentially all of our members to have the power to create most details of an event and for some trusted members we probably could let them create all of the details of an event.

I also point out that limits on the number of people with administrative authority is affecting how users come up with proposals on the Wishlist. For example the current proposal for allowing members to create their own events is at least partly an attempt to circumvent limits that were placed on the number of administrators.

We would like to see an ability to make admins that can only see certain aspects of a members profile so that we can have admins that cant see things like members payment status, or their address.

I'd like to see an Admin role established for Newsletter and/or email blasts only. Our newsletter editor shouldn't have to be a full Admin just to create/send a newsletter. Also, I find it odd, as a website Mgr/Admin, that I have to allow others Admin to access their needs who can then delete me and take over the site. I guess I'm not the fully trusting type of person. ;-)

I would like to see a website-only administrator role. It seems very strange to me that none of the current administrator roles permit this. Allowing someone to manage the website without access to member and contact records seems like it would be a common need. Even better if we could specify which web pages such an administrator could access (e.g., new pages only, related to an event, for example, without access to the rest of the site).

There are a lot of similar wishlist items to this one and WA should combine all of them so it gets implemented soon. I think the best example is what Memberplanet current has. Instead of roles, they have check boxes for different access areas like events, emails, donations, etc. Right now, the membership manager and event manager roles give non-admins way too much access. For example, the event manager can see all the members, edit their information, void invoices, and send out emails. What many organizations really need is just to allow a volunteer to view the event registrations and nothing else.