A client portal does not need to be built separately for every client, using one portal for all your clients is easier to manage and maintain. Your team might manage dozens of clients in monday.com, each with different projects, documents, services or stages in your workflow. From the client's perspective, however, the portal should feel like it belongs specifically to them.

• They should see their projects rather than everybody's projects.
• They might need different pages depending on the services they use.
• Their account information, instructions or links may also need to change automatically.

With Client Portal Builder for monday.com, one central portal can serve all of these clients while the content changes according to the person who signs in. The personalization can follow the client relationships, boards and values you already manage in monday.com instead of maintaining a separate portal structure for every customer.

Clients Board

Start with one Clients Board

Personalization starts with the Clients Board. You can think of this board as the central client directory behind the portal. Each item represents one unique client, company or account that can access the portal. The Clients Board can hold the basic information you already maintain about each relationship, such as the client name, account type, current stage, account manager or other client specific values. More importantly, each client item becomes the reference point Client Portal Builder uses to identify who has signed in.

When Client A opens the portal, Client Portal Builder knows that the visitor belongs to the Client A item on the Clients Board. That relationship can then be used throughout the portal to determine which projects belong to Client A, which pages should be visible and which client specific information should appear. The Clients Board therefore connects the portal user with the wider monday.com workflow, conceptually it works like this:

Client signs in → matching item on the Clients Board → related boards, items and client information → personalized portal experience

Shared operational boards

Show each client only their own monday.com items

One of the most common monday.com structures is a shared operational board containing work for many clients. Imagine a Projects board, where your internal team may need to see the complete board. Your client should not. When the project items are connected to the corresponding client on the Clients Board, the portal can use that relationship to decide which items belong to the person who is signed in. The team still manages one operational Projects board in monday.com, while the portal provides a different view of that board for each client.

Dedicated client boards

Use a dedicated board when each client has their own board

Not every monday.com workspace uses one shared board for all clients. Sometimes each client already has their own project, account or service board. Client Portal Builder can support this structure through dedicated boards. The important concept is that these client boards share one common structure.

You start with a template board that defines the columns used by the dedicated client boards. When another client needs their own board, that template is duplicated and becomes the starting point for the new client board:

Project template board →

• Client A Project board
• Cliebt B Project board
• Client C Project board

Each client can then have their corresponding dedicated board assigned to them. The portal section itself does not have to be recreated for Acme, Westwood and Northstar. The same section can resolve to a different assigned board depending on which client signs in, for example:

• Client A signs in → Projects page → Client A Project board
• Client B signs in → same Projects page → Client B Project board

This works because the dedicated boards originate from the same template and use the same expected column structure. It is therefore a good fit when your existing monday.com architecture intentionally gives each client their own board but keeps those boards standardized.

Portal content

Change pages and sections for different clients

Personalization is not limited to board items. Different types of clients may also need different parts of the portal. For example, imagine your Clients Board includes a Status column called Client type with these labels: Consulting, Agency, Managed service

• An agency client might need a Deliverables page.
• A consulting client might instead need a Sessions section.
• A managed service customer might need a Support page.

You do not necessarily need three separate portals to create these experiences. Pages and individual sections can be shown conditionally based on Status values from the signed-in client's item on the Clients Board. The central portal could therefore contain all of these sections while each client only sees the ones that apply to them. The same idea can also follow a client lifecycle, for example:

• Onboarding → show Getting Started page
• Active → show Projects and Resources
• Offboarding → show Final Documents section

Client information

Display information from the current client

Sometimes personalization is simpler than showing or hiding an entire page. You may simply want the portal to display information belonging to the signed-in client, for example:

• Account manager
  Sarah Johnson
• Contract renewal
  December 15
• Service plan
  Growth

If those values already live on the client's item on the Clients Board, they can also be used inside the portal. A Client Item section can display selected values from the current client's item directly. This makes the Clients Board useful not only for identifying who has signed in but also for holding client specific information that should be visible in the portal.

Dynamic content

Personalize text, links and embedded content

Not every personalized value needs to appear as a board field. Sometimes client information should become part of the surrounding portal content. You might want to show: Welcome back, John and Your account manager is Sarah Johnson. Or provide a link that is different for every client.

Client Portal Builder can use placeholders in supported content to insert values from the signed-in client's Clients Board item. The same concept can also be used in URLs. For example, one Embed section could use a client specific value to load a different external resource for each client without creating a separate portal page for every customer.

This is particularly useful when a shared portal layout should stay consistent while small pieces of information change dynamically. The principle is the same as with board items: maintain the source value in monday.com → identify the signed-in client → display the corresponding value in the portal

Layers

Combine different levels of personalization

These techniques become most useful when they work together. Consider a company serving two types of customers, and its Clients Board contains:

The company also has a shared operational Projects board where every item is connected to the appropriate client.

When Client A signs in, the portal could:

• show only Client A's projects
• display an Agency Resources section
• hide onboarding instructions
• show Client A's account manager
• insert Client A's name into the welcome message

When Client B signs in, the same portal could:

• show only Client B's projects
• hide Agency Resources
• display the onboarding page
• show Client B's account information
• personalize the welcome message with Client B's name

The portal structure itself is still managed once. What changes is the data and content that resolves for the signed-in client. This creates several levels of personalization:

• Items
  Which monday.com items belong to this client?
• Boards
  Does this client have a dedicated board?
• Pages and sections
  Which parts of the portal apply to this client?
• Client information
  Which values from the Clients Board should be visible?
• Dynamic content
  Which names, links or resources should change automatically?

Architecture

Choose the board structure that matches your monday.com workflow

There is no single board structure that every client portal needs to use. The important question is how your work is already organized in monday.com.

• If one operational board contains work for many clients, it usually makes sense to keep that shared structure and show each client only the items connected to them.
• If each client intentionally has their own standardized board, a dedicated board setup based on one template can let the same portal section resolve to the correct client board.
• If client related work exists as subitems directly below each client on the Clients Board, those subitems can form another client specific data source.

And some information may simply be common to everybody, in which case all clients can see the same shared board content. The goal is not to restructure monday.com purely for the portal in any case. The portal should follow the architecture that makes sense for your team's operational workflow while applying the appropriate client visibility on top of it.

One portal

Avoid building a separate portal for every client

Building one completely separate portal per client can initially sound like the easiest way to create personalized experiences. But that approach becomes difficult to maintain as the number of clients grows. Imagine you have 50 clients and want to:

• add a Resources page
• change the portal navigation
• update a help message
• introduce a new approval workflow

If every customer has an independently maintained portal, the same change may need to be repeated again and again. A central portal takes the opposite approach. Build the shared structure once. Then let monday.com determine which client specific information should appear inside it.

That does not mean every client must have an identical experience. The board items, assigned board, visible pages, sections and individual content can still change according to the signed-in client. What remains centralized is the structure you maintain.

Example

Build one portal for different client relationships

Imagine a professional services company managing all of its customers through monday.com.

The company has:

• Clients Board
  One item per customer
• Projects Board
  One shared operational board with projects connected to clients
• Client type
  A Status column distinguishing Consulting and Managed Service customers
• Account manager
  A person or text value stored for each client

The portal contains:

• Dashboard
  Visible to everybody
• Projects
  Displays only items connected to the current client
• Consulting Resources
  Visible only to Consulting clients
• Support
  Visible only to Managed Service clients
• Account
  Displays information from the signed-in client's Clients Board item

Client A signs in and sees Client A's projects, Consulting Resources and its own account information. Client B signs in through the same portal address and sees Client B's projects, the Support page and its own account information.

Summary

Let monday.com determine what each client sees

Personalizing a client portal does not have to mean maintaining a different application for every customer. When the client relationship already exists in monday.com, that structure can also determine the external experience.

The Clients Board identifies who is signed in. Board relationships determine which items belong to them. Dedicated boards can resolve to the client's assigned board when each customer has their own standardized board. Status values can determine which pages and sections appear. Client values can personalize information, text and resources. That creates one connected model:

Manage client relationships in monday.com → identify the signed-in client → resolve their boards, items and content → show a personalized portal experience

Your team maintains one central portal while each client sees the information that is relevant to them.