Who has access

The three access levels

Most Fay accounts have exactly one login for a long time, and that is fine. When you are ready to let somebody else in, say a bookkeeper or a board member who has offered to open some doors, you decide how far in they come.

Owner

Everything, including billing and inviting other people.

Staff

The whole CRM: people, gifts, events, imports. Not billing.

Contributor

People, events and the contact log. Sees no giving: not who gave, not how much.

Access levels are about scope, not seniority. A bookkeeper who does all your gift entry is staff; a trustee who is the most connected person on your board is a contributor. What differs is what each one needs to see.

Whoever signed the organization up is its owner, and an organization always keeps at least one. Fay will not let the last one be demoted or removed, because an account with no owner is one nobody can pay for or let anybody else into.

One word of warning, because Fay uses it twice: an access level says what a strong login | may open. A = link_to "role", handbook_topic_path("roles") | says what a strong person | is to your organization, and the two never meet. Somebody can be a board member on your roster without having a login at all, and the bookkeeper with the Staff access level need not appear on the roster.

The line: giving

The distinction that matters, and the one Fay is strictest about: a contributor sees no giving at all. Not what anybody gave, and not who gave, the second is not the lesser secret, and a list of your donors is worth as much to the wrong hands as the figures beside their names. Not on a person's page, not in a list, not in an export, not by typing the address in.

Concretely, a contributor has no Giving tab on a person's record, no Donations page, no receipts queue, no campaigns, no imports, and no suggestion queues, the suggestion queues are built out of giving history, so they are the same information wearing a different hat. The seasons pages go with them, because a season page is a giving report: raised, goal, and donor retention before anything else. So does ticket money on an event, and the ticket work that writes it. And so does the People directory's Giving filter, “donors”, “never given”, “lapsed since last season”, which names no figure but answers the same question, and would answer it for a whole roster at once.

What they do have is everything the outreach work actually needs: the whole People directory, every person's contact details and consent, the events with who was in the room and who had never come before, and the full contact log. They can add people, add events, log contacts, and be credited as the person who made a contact. The People export comes out the same way it goes in, the contact list, without the giving column.

The filter they work from instead is Audience, and it is the better tool for the job anyway. First-timer, returning, regular, lapsed: worked out from who actually turns up, never from money. A trustee ringing round the regulars is doing the most useful thing anybody can do with this database, and needs to know nothing about giving to do it.

This is not a matter of hiding a panel. The gift figures are never loaded for a contributor's request in the first place, which is the difference between a rule and a curtain.

Billing is a separate line again. Staff run the whole CRM and still cannot reach the card that pays for it, that stays with owners.

Inviting somebody

Team: in the account menu. Type an address, choose an access level, send. They get an email with a link that works once and expires after 14 days, and nothing at all happens until they follow it and choose a password.

You can withdraw an invitation before it is used, which kills the link immediately. You can send it again, which mints a new link and quietly retires the old one, worth knowing if the first email went to a forwarded address.

Fay refuses to invite an address that already has an account, and refuses to send an invitation your plan has no room for. An invitation waiting to be answered holds its seat, so the refusal lands on you while you can still withdraw one you have given up on, rather than on the person following the link. It also checks again at the moment somebody accepts, because a plan can change in the two weeks a link stays live.

Removing somebody

Removing a login removes access and nothing else. Every contact they logged, every import they ran, every note they wrote stays exactly where it is, those records belong to your organization, not to the person who typed them.

What changes is the attribution on the work: it moves to an owner, so the contact log still answers “who wrote this up” rather than pointing at nobody. Judgement calls they made in the suggestion queues are left unattributed instead of being reassigned, because saying somebody else made that call would not be true.

You cannot remove your own account from this page. Closing the whole organization is a different thing and lives on your account page.

Maria and the new trustee

Riverbend's incoming trustee has lived in Rhode Island for forty years and knows, in Maria's words, damn near everyone. She is going to generate more useful contacts in a season than the office does in three, and every one of them needs writing down somewhere Maria can act on.

So Maria invites her as a contributor. She gets the People directory and the contact log, and she starts recording conversations, or, more often, telling Maria about them on the phone and Maria recording them, crediting her in the Made by field so the board report can say plainly how many doors this one trustee opened.

What she does not get is the giving history, and that was never a question. It is not distrust; it is that donor giving is the most sensitive thing in the database and a trustee working the audience has no need of it. Maria did not have to remember to keep it from her. There was nowhere for it to appear.