Building a community with your app

It creates a login module, which you make mandatory or not at the entrance to the application.

Being able to close all or part of your app is decisive for many creators: it's what lets you reserve content and features for members. Beyond protecting content, closing the app encourages your users to create a profile, and so tells you more about your audience.

Dali Corp's internal app, meant for employees, is entirely closed to anyone without credentials.

Two settings combine freely:

• you close the whole application, or only part of it
• you let all your users create a profile, or you switch that option off and only admit chosen people, whose profiles you create by hand from the back office before sending them their credentials

That flexibility is what makes the feature universal: the same tool serves a public app wanting to know its readers and a strictly closed company app.

Above all, remember that authentication is the parent feature of many others: the loyalty features depend on it, as do all the community features that follow.

One fork to know about before you start. This guide describes the standard authentication flow, the one that opens accounts, groups, per-section rights, chat and the loyalty tools. There is a second one, reserved for apps selling access to their content through an in-app membership, and it only grants binary access: subscribed, or not subscribed.

The two flows are mutually exclusive. An app uses one or the other, never both. If selling memberships is part of your project, settle it before you build your community, because switching from one flow to the other undoes what you've put in place. The back office warns you explicitly at the moment of switching. The subject is covered in "Making money with your content app".

One reassuring detail as you decide: if you do switch, we migrate the accounts created with an email address, so your list of registered users follows you. Only accounts opened through a social network don't migrate.

Adding the Authentication extension creates a new Community menu in your back office. The settings themselves are in Settings › Registration process.

It also adds two sections to your app: the login section, which the back office calls the Log box and which stays at the top of your structure, and the User profile, each registered user's personal space. You make the latter reachable through a link on the home screen, a menu entry or a header button.

There you decide whether to allow account creation from the app, whether to allow access without logging in, and you edit the message shown to visitors who don't have a profile.

One option on that same screen deserves to be known before you open registrations: Force email validation at registration (double opt-in). Switched on, it only opens the account once the confirmation link has been clicked. It's one more step, and it will cost you a few sign-ups along the way. In exchange, your user list doesn't fill up with mistyped or borrowed addresses, and every account corresponds to someone who did receive your message. On an app where the account gives access to reserved content, that's the right setting.

The User profile tab lets you allow profile pictures, links to social networks, and per-user management of push notifications. That last option deserves attention: your users can then look through the history of notifications they've received and choose which streams they subscribe to.

This is also where you set up the profile fields. You can add several types of extra field, required at sign-up or not.

External connections save your visitors from creating one more password. There are three of them, and each has its own screen: Settings › Connection with Facebook, Settings › Connection with X and Settings › Sign in with Apple.

Two things to know before switching them on. None of them plugs in by ticking a box: each one requires a developer account with the service concerned, and an application declaration procedure the back office details step by step. Allow time for it, and above all don't switch them on the day before a launch.

And they don't replace account creation by email, which stays the foundation. That's what lets you recover your list if you ever change authentication system: as noted above, accounts opened through a social network don't migrate.

Community › Public/Private manages access to sections. You close the whole application or only certain sections, in one click.

Once authentication has been added, you get Community › User list, from which you manage all your registered users.

The list shows their main details and filters by most recent signups or most recent logins. You can export the data as a .csv, add a user by hand, or delete several using the checkboxes at the end of each row.

Clicking a user opens their profile in detail, which you can edit. You'll find the default fields there along with the ones you set up.

Bulk import is done from Community › User list, through the Import link at the top of the list, from a .csv file.

Two columns are mandatory and open the file: the email, which acts as the identifier, and the password, in plain text. The columns after that fill out the profile. One import carries up to 10,000 users, and an email tells you when processing is done.

A practical tip: start by running an export. That gives you a spreadsheet already in the right format, which you only have to fill with your new users, adding the password column. The safe move is to put the same neutral password for everyone, then ask your users to reset it on first login.

The User Groups extension comes into its own if you plan to restrict parts of your content. It lets you create groups and reserve sections of the app for one or several of them. Like every extension in this family, it requires the Authentication extension, and its listing shows the price that applies to your app.

A user can belong to no group, one group or several. If they're in none, they automatically join the Default group. Groups are managed from Community › User list, Groups tab.

You create as many as you like. At Dali Corp they match the company's departments: each employee reaches the content meant for their team and has a private communication space inside the app.

Groups also serve to target push notifications, which changes the quality of your communication a great deal: you stop sending everyone what only concerns some of them.

The mechanism carries well beyond the company setting, into a school or an editorial app wanting to target its readers better.

Chat is an extension too, added from the store, and it requires the Authentication extension just as groups do. Its listing shows the price that applies to your app.

Chat first brings your users closer to each other, which serves an app with a social purpose. But above all it creates a space to exchange and debate, and it improves a company's internal communication by letting employees contact each other.

The member directory is a separate section, brought by another extension in the same family. Your registered users browse other members' public profiles there and contact them from their card, and a map view lets them spot the ones nearby. That section, not the chat, is what makes your community visible inside the app.

Two limits to know before rolling it out: it's a one-to-one chat, and only text can be exchanged.

Chat is central to building a real community. Company apps and purely community apps benefit from it first, but think about bending it to other uses too, to run a customer service desk or to make an event app feel more alive.