Your own brand on the sign-in screen

Put your own app’s name on the screen people see when they connect their calendar. Included in the Scale plan.

View as Markdown

What people see

When a person connects Google Calendar or Microsoft 365, the provider’s sign-in screen names the app that is asking. By default that is CalMonkey’s app: it works at once, on every plan, and the screen names CalMonkey.

Your own brand is included in the Scale plan. Nothing changes until you set it up: each application has an Own brand tab in the dashboard, and you take the steps there yourself, whenever you are ready. You can use it in two ways:

  1. One organisation. When everyone who connects works in one company, that company’s administrator approves the app once for all of them.
  2. Your own app. Your app’s name on the screen for everybody, on a connect address of your own such as calendar.yourcompany.com. You own the app at Google and Microsoft; the dashboard gives you every value to enter and checks your set-up before you ask Google to review it.

What the screens show. Google shows your web address (“Sign in to yourcompany.com”) until it has reviewed your brand, and your app’s name and logo after that. Microsoft shows your app’s name as soon as your Microsoft administrator has approved it.

One organisation, approved once

Google Workspace. The organisation’s administrator marks the app as trusted by its client ID in the Admin console (Security, API controls, App access control). The organisation’s people then connect without Google’s warning for apps it has not reviewed. This covers accounts of that Workspace only, not personal Gmail accounts. The dashboard shows the client ID to paste. An app of your own that only your own Workspace uses can instead have the audience “Internal”, which Google does not review.

Microsoft 365. The dashboard makes Microsoft’s admin consent link for the organisation’s domain or tenant ID. An administrator opens it and approves once, for everybody in that organisation. Their people then connect without approving the app themselves, which is also the way through where the organisation does not let people approve apps.

Your own app, step by step

  1. Brand and pages. Your app name, logo, support address, home page and privacy policy: the connect page and the consent screen show the same ones.
  2. Connect domain. Choose a subdomain you own. The dashboard shows two DNS records: a CNAME that sends the traffic to CalMonkey and a TXT record that proves the domain is yours, also as a zone file. Verify checks them. The https certificate is issued automatically on the first visit. On that domain CalMonkey serves your connect pages and nothing else.
  3. Google project. Links straight into Google’s console with every value filled in: app name, authorised domain, the redirect URI on your domain and exactly the scopes CalMonkey uses.
  4. Credentials. Paste Google’s client file. For Microsoft, your administrator approves CalMonkey’s set-up app once and the dashboard creates the app registration in your organisation’s Microsoft account; or paste a client ID and secret of your own. Secrets are stored encrypted with per-organisation keys from a hardware-backed key management service, are never shown again, and are checked with Google or Microsoft when you save them. To rotate, add a second secret at the provider and upload it; the previous one can be put back for 7 days.
  5. Pre-flight checks. Before you submit: your settings and clients, and your home page and privacy policy as Google’s reviewers see them, without JavaScript: the exact app name, a paragraph about calendar use, a privacy link on your domain, a section on Google user data with the Limited Use sentence, and no firewall that turns crawlers away. Each failed check says how to fix it. Try a sign-in signs in with your own client on your domain and reports what came back, without connecting anything.
  6. Verification kit. The reason for each permission, privacy-policy wording that names CalMonkey as your service provider, and the shot list for the demo video Google asks for. You submit your app for review in Google’s console.
  7. Switch over. Switch the application to your own app when you are ready. Your code changes nothing: it sends people to the same connect address and CalMonkey takes them to your domain. Switching back is one click.
Google decides how long its review takes. Switching, either way, changes only new connections: nobody has to connect again because of it. People who connected through CalMonkey’s app keep working through it (their Google or Microsoft account still lists CalMonkey); they see your brand once they disconnect and connect again.

After the switch

CalMonkey checks your connect domain and your clients every day and tells you when something needs attention, such as a DNS record that was removed, a secret close to its expiry, or a Google client nobody has used for months (Google deletes OAuth clients that are unused for six months).

Changing your app’s name, logo, home page, privacy link or domain at Google starts a new review there; the dashboard asks you to confirm before you change them. Apple iCloud has nothing to register: on your domain the iCloud connect page carries your brand too. The API is the same whichever app people sign in through: see the API reference.

If you leave the Scale plan while your own app is in use, it stays in use for new connections for 30 days, or until the end of the period you paid for if that is later, and the dashboard says until when. After that, new connections use CalMonkey’s app. People who connected through your own app keep working either way.