It is a tile on the Okta dashboard that opens a web address. Nothing more, nothing less.

Okta is a service that helps companies manage who can use which applications. People sign in to Okta once, and they see a page called the dashboard. On the dashboard is a collection of tiles. Each tile stands for an application or a website. Clicking a tile takes you there.

Most tiles do something clever: they sign you in to the application automatically. A bookmark app does not. It is a tile that only opens a web address. If that website asks you to sign in, you must do so yourself. Okta passes along no password, no token, and no proof of who you are.

Why do bookmark apps exist?

Many useful destinations do not need automatic sign-in. A company news page may be open to everyone inside the network. A public help site needs no account. A training portal may have its own separate login that Okta cannot connect to. In all these cases, the value is not security. The value is findability: putting the right link in front of the right people without making them hunt for it.

A small handful of ideas covers everything you need.

How the pieces fit

An administrator creates a bookmark app in the Admin Console, gives it a label and a URL, chooses a picture, and assigns it to a group. The next time anyone in that group opens their dashboard, the tile is there. They click it, and their browser opens the address.

Okta tiles come in several kinds. Knowing the differences prevents the most common misunderstanding.

Okta can connect to applications in different ways. Each way shows a tile, but what happens after the click is very different. Here are the three families that matter most for beginners.

flowchart TD
  C["Person clicks a tile"] --> K{"Kind of tile"}
  K -- "Federated single sign-on" --> F["Okta sends a signed message"]
  F --> F2["Application trusts it and opens signed in"]
  K -- "Stored-password sign-on" --> P["Browser helper fills the saved password"]
  P --> P2["Application opens signed in"]
  K -- "Bookmark" --> B["Browser simply opens the address"]
  B --> B2["Destination asks for its own sign-in, if it needs one"]
    

Follow one click from start to finish and notice how little Okta does after the click.

sequenceDiagram
  participant P as Person
  participant B as Browser
  participant O as Okta
  participant S as Destination website
  P->>B: Open the Okta dashboard
  B->>O: Request the dashboard
  O->>O: Check the Okta session
  O->>B: Show the tiles assigned to this person
  P->>B: Click the bookmark tile
  B->>S: Open the saved address
  Note over O,S: No identity or password is passed on
  alt Destination is public
    S->>P: Page opens
  else Destination has its own login
    S->>P: Ask the person to sign in
  end
    

A bookmark app has very few settings. That is part of its charm.

When an administrator creates a bookmark app, they fill in a short list of details. The exact names of screens and boxes may differ in your Okta version, but the ideas are the same.

What is missing

Notice what a bookmark app does not have: no sign-on method to choose, no certificate to exchange, no user mapping, no password settings. Because Okta is not signing anyone in, none of those exist. This is why bookmark apps take only minutes to create.

Here is the whole process in plain words, with the reasoning behind each step.

A tile with a clever name that nobody understands is a tile nobody clicks.

People scan a dashboard in a second or two. They look for a word they already know. If the tile says “Project Phoenix Portal v2” and the person is searching for “Holiday Request,” they will pass right over it. Good labels follow the words people use.

People recognize pictures faster than words. A good logo turns a tile into a landmark.

Every tile carries a small picture. Many bookmark apps start with a generic icon, which makes all your links look alike. Replacing it with a clear, relevant image helps people find what they need at a glance.

A tile is only useful to the people who can see it. Assignment decides who that is.

Creating a bookmark app does not put it on anyone’s dashboard. The administrator must assign it. An assignment can go to individual people or to groups. Groups are far better: when someone joins or leaves a group, their dashboard updates by itself.

flowchart LR
  G1["Group: All Employees"] --> T1["Tile: Company Intranet"]
  G1 --> T2["Tile: IT Help Desk"]
  G2["Group: Finance"] --> T3["Tile: Expense Guide"]
  G3["Group: Engineering"] --> T4["Tile: Engineering Handbook"]
  P1["Person: new hire in Finance"] --> G1
  P1 --> G2
    

What happens when someone leaves a group

When a person is removed from a group, the tile disappears from their dashboard. This is helpful for tidy-up but is not a security measure for the destination. If the person knows the address, they can still type it into a browser. Only the destination’s own sign-in can stop them.

Not every link makes sense on every screen. Okta lets you choose where a tile appears.

People use the dashboard on desktop browsers and on phones. A link to a large spreadsheet tool may be awkward on a small screen, while a link to the company directory is useful anywhere. Visibility settings let you hide a tile on the web dashboard, on mobile, or both, while still keeping it assigned.

Ten tiles are easy. A hundred tiles are a mess unless someone plans how they are grouped.

The Okta dashboard can hold many tiles, and each person’s dashboard may show dozens. Newer versions of the dashboard let people sort tiles into sections or tabs, and administrators may be able to influence how tiles are grouped for everyone. Exact features vary by version, so check what is available to you. The thinking behind good organization stays the same.

Principles of a tidy dashboard

A good tool used in the wrong place causes trouble. Here is how to tell when a bookmark fits.

flowchart TD
  Q["New destination to add"] --> A{"Does it need a sign-in?"}
  A -- No --> B1["Bookmark is a good fit"]
  A -- Yes --> C{"Does it support modern single sign-on?"}
  C -- Yes --> D["Set up federated single sign-on"]
  C -- No --> E{"Is the data sensitive?"}
  E -- Yes --> F["Ask the vendor for modern sign-on, or reconsider the tool"]
  E -- No --> G["Bookmark or stored-password sign-on, with a note to revisit"]
    

Many tiles begin life as bookmarks and grow into full integrations. Plan the journey.

A common story goes like this. A team adopts a new online tool and asks for a quick link on the dashboard. The administrator makes a bookmark. Months later, the tool holds important data, and the security team asks for proper single sign-on. The tile should be upgraded, and people should hardly notice.

The “Request integration” option

When creating a bookmark app, Okta may offer a checkbox that asks Okta to look into building a proper integration for that website. Ticking it is a way of saying, “We would like single sign-on for this service.” It is not a promise that one will appear. It is a signal to Okta, and it can be a useful nudge for popular tools.

The URL is the one thing a bookmark app cannot work without. Treat it with care.

A URL is a web address. Its quality determines whether the tile feels helpful or frustrating. Here are the choices worth thinking about.

A bookmark does not protect anything. It only points. Understanding this keeps you out of trouble.

Because a bookmark app passes nothing to the destination, the destination cannot tell that the visitor came from Okta. Anyone who knows the address can open it. If the page is public, that is fine. If the page holds private information and relies on being “hidden,” then the privacy is an illusion.

Even though a bookmark does not protect its destination, it still sits inside a well-guarded home.

Before anyone can see a bookmark tile, they must reach the Okta dashboard. That requires signing in to Okta, under rules the organization has set: passwords, second factors, session lengths, and device or location checks. So while the tile is not a lock, the lobby where tiles live is guarded.

flowchart TD
  P["Person"] --> OK{"Okta sign-in rules pass?"}
  OK -- No --> X["No dashboard, no tiles"]
  OK -- Yes --> D["Dashboard with assigned tiles"]
  D --> T["Click bookmark tile"]
  T --> W{"Destination requires its own sign-in?"}
  W -- Yes --> L["Destination login protects the page"]
  W -- No --> O["Page opens for anyone with the link"]
    

Websites move, reorganize, and disappear. A tile that worked last year may now lead to an error.

Link rot is the slow decay of web addresses. A tool is renamed, a page is reorganized, a project ends, or a domain expires. The tile stays on the dashboard, but clicking it shows an error. People lose trust in the dashboard, and they stop clicking.

People change roles all the time. Tiles that follow groups keep up without effort.

Every organization has people who join, move, and leave. This is the lifecycle of access. If tiles are assigned through groups that are kept up to date from the human-resources system, the dashboard adapts automatically.

When you have three bookmark tiles, clicking in a form is fine. When you have three hundred, you need a better way.

Okta offers management interfaces that let trusted tools create, read, update, and delete applications, including bookmark apps, without anyone clicking through screens. In plain words, a small program can read a spreadsheet of labels and addresses and create all the tiles for you. This is especially helpful when setting up a new organization, moving between Okta environments, or keeping tiles in step with an outside list of company links.

Attackers love trusted dashboards. A fake tile among real ones is a dangerous trick.

People trust what is on their Okta dashboard. That trust is the reason a rogue bookmark is dangerous. Imagine a tile labeled “Payroll Update” that leads to a page that looks like a real sign-in screen but belongs to a criminal. A hurried employee may type their password without a second thought.

Bookmarks are simple, but the questions an auditor asks about them are still reasonable.

Even simple tiles benefit from a few measurements.

Okta records administrative actions, such as creating, changing, or assigning an application, and it records sign-ins to the dashboard. It may also record that a person opened a tile. These records help you answer practical questions.

A tile depends on two things working: Okta and the destination. Know which one is failing.

A bookmark tile stops working for only a few reasons. Either the dashboard cannot be reached, or the tile is missing, or the destination does not respond. These are different problems with different fixes, and keeping them separate saves time during an incident.

Making the dashboard less of a single point of failure

If your most important internal links live only as tiles, an Okta outage hides them too. Keep a simple backup, such as a plain list of key addresses on an internal page that does not depend on Okta, for the few links people need during an emergency, like the help desk and the incident status page.

The tile is the same everywhere, but the experience around it can differ.

Because a bookmark is only a web address, it opens in whichever browser the person is using. On desktop, the browser may open the page in a new tab or window. On a phone, the page may open inside the Okta app’s own viewer or in the phone’s default browser, depending on settings. These differences rarely change the logic, but they affect how smooth the experience feels.

A good set of bookmark tiles is curated like a small library, not dumped like a drawer of keys.

Many companies end up with hundreds of bookmark apps because adding one is so easy. Without a plan, the dashboard becomes a junk drawer. A link catalog is a short, maintained list that says what each tile is for, who owns it, and who sees it.

Admission rules for new tiles

• The link serves a clear, common need for a defined audience.
• It has a named owner who agrees to keep it healthy.
• It uses a secure address.
• It does not hide sensitive material behind obscurity.
• It has a review date.

These are tried shapes for using bookmark apps well.

These mistakes look harmless and cause confusion or risk later.

A short list to carry into a planning meeting.

Work through a short set of questions in order. Most problems are solved in the first two or three.

flowchart TD
  S["Person reports a tile problem"] --> Q1{"Can they see the Okta dashboard?"}
  Q1 -- No --> A1["Sign-in or session problem - check Okta sign-in and status"]
  Q1 -- Yes --> Q2{"Is the tile on their dashboard?"}
  Q2 -- No --> Q3{"Is it assigned to one of their groups?"}
  Q3 -- No --> A2["Fix assignment or group membership"]
  Q3 -- Yes --> A3["Check visibility settings for web or mobile and wait for group updates"]
  Q2 -- Yes --> Q4{"Does clicking open the right page?"}
  Q4 -- No --> A4["Check the saved address and any redirects"]
  Q4 -- Yes --> Q5{"Does the page ask for a sign-in?"}
  Q5 -- Yes --> A5["Expected for a bookmark - the destination controls its own login"]
  Q5 -- No --> A6["Check the destination site and the network"]
    

Four stories show bookmark apps at work.

The tile is only half of the experience. Short, kind guidance does the rest.

A good dashboard is supported by a little plain-language help. Without it, people guess what tiles do and form wrong ideas. With it, they use the dashboard with confidence.

Because tiles are trusted, the power to create them should be shared with great care.

Okta lets organizations give different administrators different powers. Some can do everything. Others can manage only certain groups of people or only certain applications. This is called delegated administration. For bookmark apps, it is wise to use it. The person who maintains the intranet links does not need the power to change security policies or reset the passwords of executives.

Questions to ask when delegating

• Does this person need to create tiles, or only to change their audience?
• Can their own account be protected with strong sign-in rules?
• Will changes they make be logged and visible to the security team?
• Is there a second person who reviews new addresses?

A few simple questions, answered honestly, show which tiles should stay plain and which should grow up.

You do not need a complicated model. Give each candidate link a small score on four questions. Add them up, and let the total guide the decision. The numbers below are only an example; adjust them to your own situation.

A dashboard is for everyone. That includes people who use screen readers, people who read other languages, and people on very small screens.

Tiles are small, and it is easy to design them in ways that exclude some users. A few habits make the dashboard friendlier to everyone.

A calm, staged rollout beats a big-bang launch every time.

Imagine a company that wants to replace scattered links in email signatures, wikis, and chat messages with one tidy dashboard. Doing it all in a day would overwhelm everyone. A phased approach spreads the work and the learning.

If you cannot say whether the dashboard is helping, you cannot improve it.

A bookmark program is successful when people find what they need faster, with fewer questions, and with fewer mistakes. A small scorecard checked every quarter keeps everyone honest.

Different people ask different questions. Having short, honest answers ready makes decisions easier.

A tile is simple, but a broken tile damages trust quickly. A short test routine prevents most embarrassment.

Testing a bookmark does not take long. It is mostly a matter of looking at the tile the way a real person will see it, on a real device, for the first time. A written checklist makes sure nothing is forgotten, even on a busy day.

Let us design a dashboard from nothing for a mid-sized company, using everything learned so far.

Imagine a company with five hundred employees, a human-resources team, a finance team, an engineering team, and a customer support team. Everyone needs a handful of common links. Each department needs its own. A few tools hold sensitive data.

Step one: list the audiences

Step two: choose the treatment

Step three: arrange and name

Place the daily tools first, group help and learning links together, and use plain labels such as “HR Self-Service,” “IT Help Desk,” and “Holiday Calendar.” Use consistent pictures for internal links so they form a recognizable set. Hide any desktop-only tool on mobile.

Step four: protect and maintain

Limit creation of tiles to two trained administrators. Keep the catalog. Alert the security team on changes to tile addresses. Test links monthly. Review the whole set each quarter and record any bookmark that should be upgraded.

Sometimes a tile points to the wrong place, or to a harmful one. Speed and calm matter.

Whether a tile was changed by mistake or by an attacker, the first goal is the same: stop people clicking it. After that, work out what happened and tell the right people.

Tools change, but the need for a trusted front door to work stays.

Over time, more vendors support modern sign-on, more of your tools move into the cloud, and more of your links become real integrations. That does not make bookmark apps obsolete. Even in a company with every major tool connected to single sign-on, there will always be plain links worth sharing: policies, guides, public documents, status pages, and the countless small resources that make daily work easier.

Some links are needed for a week, a quarter, or a single event. They deserve their own handling.

Companies run campaigns, open enrollment periods, annual surveys, safety drills, and special projects. Each needs a link, for a limited time. Because a bookmark tile is quick to make, it is tempting to create these tiles and forget them. A year later, the dashboard is full of references to events that ended long ago.

Habits that keep temporary tiles from piling up

• Write the end date in the catalog at creation time.
• Name an owner who will be reminded as the date approaches.
• Hide first, delete later, so the tile can be restored if needed.
• Reuse seasonal tiles where possible instead of creating new ones each year.

The dashboard is one way to share a link among many. Use it where it shines.

Companies have many places to put links: email, chat channels, wikis, intranet pages, and printed posters. A tile is best for links that people need repeatedly and from anywhere, and that benefit from sitting beside the tools people already open from Okta.

The best programs combine these. A tile opens a hub page that explains and organizes. An email announces something new. A chat message answers a quick question and points to the tile for next time.

The simplicity that makes bookmark apps popular is also their limit.

A steady rhythm keeps even a large set of tiles healthy.

flowchart LR
  A["Request"] --> B["Assess"]
  B --> C["Create and label"]
  C --> D["Test"]
  D --> E["Assign"]
  E --> F["Record"]
  F --> G["Check and review"]
  G --> H{"Still needed?"}
  H -- Yes --> G
  H -- Upgrade --> B
  H -- No --> I["Retire"]
    

Three people, three days, one dashboard.

Neha, a new employee in marketing

On her first morning, Neha signs in to Okta and sees fourteen tiles. Six are real single sign-on applications such as email and chat. Eight are bookmarks: the leave calendar, expense guide, brand guidelines, IT help desk, and others. She clicks the brand guidelines tile and a page opens at once, because it is open to staff on the company network. She clicks the expense guide and sees the finance system’s own login page, since that tile is a plain bookmark. She signs in with her separate expense account and asks the help desk why. They tell her the finance team is planning to move that tool to proper single sign-on next quarter.

Arjun, a team lead who changes departments

Arjun moves from engineering to product. The next morning his group memberships update. His dashboard loses the engineering handbook and build-status tiles and gains the product roadmap and research library tiles. He does nothing. A week later he notices that the engineering handbook tile is gone and asks why. The help desk explains that it followed his old group, and that he can request it again if he still needs it.

Kavita, the administrator who looks after the catalog

Once a month Kavita runs a check that visits every bookmark address. It reports two failures: a training portal that moved and a campaign page that ended. She contacts the owners, updates one address, and hides the other. She reviews new tile requests, rejects one that would have placed an access token inside the address, and approves another after asking for a company-owned redirect. She updates the catalog and adds a bookmark with a sensitive destination to the list of tiles that should be upgraded to single sign-on.

Quick reminders for the words used most often.

A bookmark app is a signpost, not a lock. Use it as one.

A bookmark app is the simplest tile in Okta: a label, a picture, and an address, assigned to people through groups. It makes links easy to find, and it needs almost no setup. It does not sign anyone in, pass any identity, or protect its destination. The best programs use bookmarks for harmless links, upgrade sensitive tools to real single sign-on, name tiles in plain words, keep owners and reviews, limit who can create tiles, and check links regularly.