Requiring sign-in
By default, apps are public, meaning that anyone with a link to a public app can access it. That makes it hard to revoke access from, say, former employees or contractors. Also, public apps are sometimes indexed by search engines, making them show up in search results.
For apps used internally in an organization, we recommend private apps, especially if they contain sensitive information. These apps require users to sign in before being granted access and require you to define who those users are. Private apps have been engineered to support thousands of users.
When a private app is started, a sign-in screen is displayed. You can customize it if your apps are on the White Label plan:
The user name and password are stored, saving your users the trouble of signing in every time. Once accessed, apps work offline, but require your users to sign in at least once every 30 days.
Your users select a password when they first run the app, by clicking a link in an email you send them through Calcapp Creator. The app’s sidebar enables them to change their password or sign out. They also get access to a password reset feature:
These user interface elements app follow the theme colors you have defined and are presented in the language you have selected for your app.
Making an app private
Make an app private by selecting a private plan for it. This window appears when you select Change plan… from the main menu :
The next guide covers selecting a plan. For testing purposes, you can go with the Free plan.
Defining users
Here’s what the top of the inspector looks like when your app is private:
Press Manage users to determine the users who can sign into your app:
Add users simply by typing their email addresses into the Add new field.
Inviting new users
In order for your users to start using your app, you need to invite them through email. Press the Publish/Update app button in the top bar to bring up the Publish window:
The Publish window for private apps doesn’t allow you to type a list of recipients manually. Instead, all users who can run your app are listed to the left of the email message, along with checkboxes determining whether users are included among the recipients.
Users who haven’t yet signed into your app and selected a password are listed as new users. Click the New users heading to conveniently check all checkboxes belonging to new users.
If you share a private app with a user who has already signed in and selected a password, a regular link to the app is sent. New users, however, get sent a special link that signs them in automatically and allows them to select a password.
Defining tags
A user can be associated with one or several tags, which are simple text strings you select. Tags are primarily used to control whether a user is allowed to launch a certain private app, but have several other uses.
Use the Manage users window to assign tags to users. By default, every user is associated with the tag User. To add a tag to a user, simply start typing in the field marked +Tag next to a user. Remove a tag by clicking its symbol:
In this image, most users have only been assigned the default User tag, but three users have been assigned the Beta tester tag and one has been assigned the Administrator tag.
Using tags to control who can sign in
The list of users is shared between all private apps, so if you do nothing, all users you define can sign into any private app you create. To only allow certain users to access your app, find the Users section in the inspector and select Only some users can sign in from the drop-down that initially reads All users can sign in:
The private app in the image above is a beta version of a company’s regular app. As such, only administrators and beta testers may sign into it, meaning that the User tag has been explicitly disabled.
Tags are flexible and you can use them however you wish. Let’s say you have three private apps and there’s no overlap in terms of the users who can sign into them. The best course of action in this scenario is to create one tag per app and adjust the app settings such that only users tagged with the proper app tag are allowed to sign in.
Using tags when sharing app links
The Publish window, which appears when you press the Publish/Update app button in the top bar, lists users by tag. As users can be associated with several tags, the same user may appear several times under different tag headings. Click a tag heading to select or unselect all users with with that tag.
Here’s the Publish window with all users tagged with Beta tester selected:
Consider adding tags to users for the sole purpose of making it easier to send — or not send — email to them. For instance, an app may be accessible to thousands of users in your organization, but only a couple of hundred users may want to be notified when you make changes. Use a special tag for these users to make it easier to send email to them exclusively.
Using tags through formulas
What if you want certain parts of your app to only be accessible to your power users or beta testers? Maybe you’d like to enable trusted users to add rows directly to your Google Sheets spreadsheet, but force other users to send you an emailed report instead so you can look over the data first?
All this is possible with tags and the formula function USERHASTAG. It takes a tag as its sole parameter and returns TRUE if the signed-in user is associated with that tag and FALSE otherwise.
For instance, you can display a field only to users with the tag Beta tester by associating the formula USERHASTAG("Beta tester")USERHASTAG("Beta tester") with the Visible property of the field. Similarly, you can associate the same formula with the Visible property of a list screen navigator to only make that navigator available to beta testers or with the NextScreenAvailable property of a form screen to only allow beta testers to access the next screen.
If you’d rather base decisions on the user’s email address, write App.UserEmailAddressApp,UserEmailAddress in your formulas to access the address.
Next, learn about selecting a plans for your app »