Networks
How to create an Arbor network and decide how its members sign in, where they land, and what the screens and emails look like.
Overview
A network is a group of people with shared access: a membership, a cohort, a peer group, a household, the users of one portal. Every member belongs to exactly one network, and everything about signing in is set on the network: which methods are allowed, whether people can sign themselves up, how strict MFA is, and the branding on every screen and email. The network also lists the roles its members can hold.
Networks are separate from each other. The same username can exist in two networks as two different members, and a session in one says nothing about the other.
Networks live on the Arbor Networks tab. Each network's record page has three tabs, with the Provision Arbor Member tool beside them:
| Tab | What it shows |
|---|---|
| Details | The network's settings, covered on this page. |
| Members | Everyone who can sign in, by username and status. See Members. |
| Elements | Every element in the network, relationships included. |
Creating a network
- Open Arbor Networks and click New.
- Give it a Network Name. Members see it in the emails Arbor sends them.
- Leave Status at Provisioning while you set it up.
- Choose its sign-in methods in Allowed Auth Methods. Until at least one is selected, nothing on the network works.
- Fill in the URLs for the pages you built (see Sign-in Pages), and the branding.
- Save, then set Status to Active when members can start using it.
Status
| Status | What it does |
|---|---|
| Provisioning | The default. Sign-in and provisioning work. |
| Active | The same as Provisioning, for a network that is live. |
| Inactive | Switches the network off: every sign-in, link, sign-up and provisioning attempt fails, Log in as member is unavailable, and members already signed in are signed out the next time their session is checked. Members and their records are kept. |
Sign-in methods
Allowed Auth Methods is the master control. A member can only be provisioned with, sign in with, or use as a second factor a method selected here. Leave it empty and every sign-in and every provisioning attempt on the network fails.
| Method | How a member signs in |
|---|---|
| Password | Username, then password. Members choose their own password, either by signing up or from a setup invitation. |
| Email Code | Username, then a 6-digit code emailed to them. A code lasts 10 minutes. |
| Username | Username alone. Suits only content that would do no harm in the wrong hands. |
| Authenticator App (TOTP) | Username, then a code from an authenticator app. A member sets the app up while signed in, so it cannot be anyone's first method: it serves as a second factor, or as a method a member switches to later. |
| Magic Link | A link emailed or handed to them. It keeps working until a new one is issued. |
| One-Time Magic Link | A link that works once and expires after seven days. To get back in, the member asks for a new one. |
A member's username defaults to their email address, so in practice most members sign in with their email.
Five wrong attempts lock a username for 15 minutes, with Too many failed attempts. Please try again later. on the sign-in page. The count covers every step, codes included, and clears on a successful sign-in.
URLs
| Field | What to put in it |
|---|---|
| Auth Site URL | The full URL of a members-only page on your site, one with the Auth Guard on it. Not the sign-in page. Every magic link points here, and the guard signs the member in when they arrive. Both link methods need it, and so do Log in as member and sign-up by link. |
| Registration Site URL | The full URL of the page with the Registration Form. Setup invitations to password members point here, so provisioning a password member needs it. |
| Login Redirect URL | Where the Login Form sends a member once they are signed in. A member the guard sent to sign in goes back to the page they came from instead. Set it: without it, the Login Form reloads itself. |
| Registration Redirect URL | Where the Registration Form sends a member once they have signed up with a password. |
The two redirect fields take a full URL or a path on the same site, such as /members/s/home.
Self sign-up
Self Signup Enabled opens the Registration Form to anyone who finds it. It is off by default; leave it off for networks you fill yourself.
When it is on, what the form offers follows Allowed Auth Methods:
| The network allows | The form offers |
|---|---|
| Password | Set a password |
| Magic Link or One-Time Magic Link, with an Auth Site URL set | Email me a sign-in link. A new member gets One-Time Magic Link when it is allowed, Magic Link otherwise. |
| Both | A choice between the two |
| Neither | Sign-up isn't available right now. Please contact your administrator. |
A sign-up from a new email address creates a Contact for the person and ties the new member to it. Duplicate rules do not stop that Contact being created.
With it off, the Login Form hides its Register link. A password member you invited can still finish setting up.
MFA
MFA Policy sets the least a member must present on top of their first sign-in step.
| MFA Policy | At sign-in |
|---|---|
| Off | No second step, unless the member has one of their own (set in Member Access). Arbor never suggests one. |
| Encouraged | No second step is required. A member without one who signs in on the Login Form is offered an authenticator app first, and can choose Skip for now, which hides the offer on that browser for 30 days. New password sign-ups get the same offer. |
| Required (any factor) | Password members also enter an emailed code or an authenticator code. Members whose first step is an email code, a username or a link need the authenticator app, because a second email to the same inbox proves nothing new. |
| Required (authenticator app) | Every member enters an authenticator code. |
- The factor has to be allowed too. An emailed code is only offered when Email Code is in Allowed Auth Methods, and the authenticator only when Authenticator App (TOTP) is. A network that requires the app without allowing it turns every affected sign-in away with This network requires a second factor that is not enabled. Please contact your administrator. The Encouraged offer likewise appears only when the app is allowed.
- A member without an authenticator is walked through setting one up on the Login Form, by QR code or setup key, before they finish signing in.
- Magic-link members finish on the Login Form. When a link member needs a second factor, the Auth Guard shows One more step to sign in. Redirecting... and passes them to the Login Form, which asks for the authenticator code (or sets the app up), then returns them to the page the link opened.
- Trust this device for 30 days appears on the second step. A member who ticks it skips the second step on that browser for 30 days, links included.
- A member's own second factor counts on any network, Off included. The stricter of the two applies.
Persistent sessions
By default a sign-in lasts as long as the browser tab it was made in. It ends when the tab is closed, after two hours without activity, or after 24 hours however active the member is.
Persistent Sessions Enabled keeps members signed in on a browser across restarts, until they sign out or clear the browser's data. When a sign-in runs out, the Auth Guard starts a new one without asking. Each member can stay signed in on up to six browsers; signing in on a seventh signs out the one used least recently. You can see those browsers, and sign them out, in Member Access.
Turn it on only for lower-security networks. Anyone who sits down at a signed-in browser is that member.
Roles
Roles lists what a member of this network can be, one per line:
Staff
Volunteer
Board Member
Arbor does not act on roles itself. They are for the apps built on the network: a Flourish Core portal, for example, reads a member's roles to decide what they can reach. There is no fixed list, so each network names its own, and a network with no use for them leaves the field blank.
- A member can only hold a role listed here. Case does not matter when a role is given; Arbor saves it the way the network spells it.
- Removing a role takes it from every member at once. Their records still carry the name, but it grants nothing. Renaming a role is therefore removing the old name, adding the new one, and giving it to members again.
- Saving tidies the list. Spaces are trimmed and blank lines and repeats dropped. Semicolons work as separators too.
Giving members their roles is covered in Members.
The field is in the Access section of the network page. An org that installed Arbor before roles existed won't have it there, because a package upgrade does not change page layouts. Add Roles to the Access section of Arbor Network Layout, and to the Authentication section of Arbor Element Layout (Setup, Object Manager, then the object, then Page Layouts).
Branding
Logo URL and Brand Color brand every sign-in screen and every email for the network.
| Field | What it does |
|---|---|
| Logo URL | A public URL for your logo image. It tops the Login Form, Registration Form, Request Link and Reset Password screens, and every email. Blank shows Arbor's own logo on the screens and the network's name in the emails. |
| Brand Color | A hex color such as #3d2170. It colors buttons, links and the background pattern on screen, and the header and button in emails. Blank uses Arbor's default purple. |
The logo has to load without anyone signed in, since email clients fetch it too. If it shows in email but not on the site, the site is blocking the image's domain: add that domain to the site's trusted sites.
A single page can override both through its component's Config (JSON). See Sign-in Pages.
Emails
Arbor sends three kinds of email for a network, each with a subject and body you can replace:
| Sent when | Fields | |
|---|---|---|
| Code | A member signs in with an emailed code, gets one as a second factor, signs up with a password, or resets their password | Email Code Subject, Email Code Body |
| Sign-in link | A link member is provisioned with a welcome email, asks for a link, signs up by link, or an admin emails one | Email Link Subject, Email Link Body |
| Setup invitation | A password member is provisioned with a welcome email, or an admin resends the invitation | Email Claim Subject, Email Claim Body |
Leave a field blank to keep Arbor's default. The default subjects are:
| Default subject | |
|---|---|
| Code | Your {{networkName}} verification code, or password reset code, or registration code, by purpose. An Email Code Subject replaces all three. |
| Sign-in link | Sign in to {{networkName}} |
| Setup invitation | Set up your {{networkName}} account |
Write the body as plain text. Arbor wraps it in the branded layout, and adds the code, or a button carrying the link, below your text by itself. A body never has to include them, and cannot leave them out by mistake. Three tokens are filled in when the email is sent:
| Token | Becomes | In |
|---|---|---|
{{networkName}} | The network's name | Every subject and body |
{{code}} | The code | Code emails |
{{link}} | The sign-in or setup link | Link and invitation emails |
Email From Name is the sender name members see. Blank uses the network's name. It is ignored once Sender Email is set in Setup, since that address brings its own display name.
The fields are in the Email section of the network page. An org that installed Arbor before that section existed won't have it, because a package upgrade does not change page layouts. In that case, add Email From Name and the six subject and body fields to Arbor Network Layout (Setup, Object Manager, Arbor Network, Page Layouts), in a section of their own.