• Learn
  • Blog
  • Pricing
  • About
  • Sign in

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 e-mail 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 plans window

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:

The inspector for a private app

Press Manage users to determine the users who can sign into your app:

The Manage users window without any users added

Add users simply by typing their e-mail 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 e-mail. Press the Share/Update app button in the top bar to bring up the Share window:

The Share window for private apps

The Share 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 e-mail 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:

The Manage users window populated with users and tags

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 inspector for a private app

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.

The Share window, which appears when you press the Share/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 Share window with all users tagged with Beta tester selected:

The Share window for private apps with beta testers visible

Consider adding tags to users for the sole purpose of making it easier to send — or not send — e-mail 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 e-mail 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 e-mailed 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") with the Visible property ot the field. Similarly, you can associate the same formula with the Visible property of a list panel option to only make that option available to beta testers or with the NextPanelAvailable property of a panel to only allow beta testers to access the next panel.

If you’d rather base decisions on the user’s e-mail address, write App.UserEmailAddress in your formulas to access the address.

Next, learn about selecting a plans for your app »