Wix Client Portal: Plan Access, Records and Custom Features
Yes, you can build a Wix client portal. Start with Members Area for individual logins and restricted pages. Then decide whether clients need shared resources, existing Wix account features, or their own project records. That last requirement determines much of the development work.
A login screen is only the entrance. A useful portal also needs clear rules for who can read and change each record, an easy next action for the client, and a manageable process for your team.
This guide helps Ontario business owners scope that work before commissioning a build. CodeMasters provides custom web development, including member functionality, databases and business workflows. You can book a free 30-minute consultation to discuss your current site and the tasks clients need to complete.
Start with the job your client needs to do
“Client portal” can mean very different things. A consultant may want every client to access the same resource library. A contractor may need each customer to see their own project status. A membership business may already have suitable account features within its existing Wix apps.
Write the first release as a short sentence: “After signing in, a client can view their project status and submit a change request.” This gives the developer something testable. “A dashboard like our competitor's” leaves the important decisions open.
Use these questions to narrow the scope:
What should clients be able to do without contacting your team?
Is the information shared with all members, one person, or several people at one company?
Who creates each record and keeps it current?
Which actions change a commitment, price or project status?
Where does your team already manage this information?
If staff must update both the portal and a separate spreadsheet, include that ongoing work in the decision. Connecting systems may help, but a second copy of every record brings reconciliation and maintenance responsibilities.
Compare three practical approaches
Requirement | Starting approach | Check before committing |
|---|---|---|
Every approved client reads the same resources | Members Area with restricted pages | Registration, member roles and page access |
Clients manage an existing Wix service or purchase | Relevant Wix app and its account pages | Whether the current app covers the actual customer task |
Clients view or change custom project records | Members Area plus CMS and suitable access logic | Record ownership, permitted fields and account separation |
Several employees share one customer's projects | Explicit company membership and project access rules | Invitations, staff departures and access removal |
Start by reviewing the Wix Members Area options. Use native functionality where it covers the requirement. Add custom Velo work for a defined gap, such as assigned project access, controlled updates or an external-system connection.
A portal with a few carefully chosen actions is easier to operate than a large dashboard with unclear ownership. Choose one workflow first, then expand after your team can maintain it reliably.
Page access and record access answer different questions.
Separate page access from record access
Think about two questions. May this person open the page? Which records may this person receive after the page opens?
Page permissions answer the first question. CMS permissions and any custom backend authorization must answer the second. A page restricted to members can still contain data that requires tighter access rules.
The mistake to avoid is giving every member permission to read the whole project collection, then filtering the visible list to the current client. Wix explains that collection permissions govern API access as well as what appears through page elements. A display filter alone is an insufficient boundary for private customer records.
For a concrete planning example, imagine two customers, Client A and Client B, each with a different project. Both may open the portal. Client A should receive only the records assigned to A, and Client B only those assigned to B. Your developer should be able to explain where that rule is enforced and demonstrate both allowed and denied access.
Keep internal notes apart from customer-facing updates. It is easier to review an explicit set of permitted output fields than to send a complete record and hide a few fields in the interface.
Set page permissions in Wix Studio
Once the Members Area and required member roles exist, follow Wix's member-page permissions instructions:
Open Pages in the Studio Editor.
Open More Actions beside the relevant page, then Settings.
Select Permissions, then Members only.
If access should be role-specific, choose Specific members, enable Members with roles, and use Manage Roles to select the intended roles.
Click Apply.
For pages within the Members Area, Wix also provides Site Member Access in the dashboard. Choose Set Access, select the pages available to each role, and save.
Use roles to express a useful group, such as clients who may enter a resource section. For individual project records, define the separate record-level rule as part of the data design.
Check CMS permissions before connecting private records
Wix's current collection-permissions walkthrough starts in CMS. Open the collection's More Actions menu and choose Permissions & privacy.
Review each operation separately: view, add, update and delete. Under Advanced, these can be configured by role. Give people the access their task requires. A customer who can submit a request may have no reason to delete it or edit the final quoted amount.
The Item's creator option applies to records the member created. A project entered by your staff and assigned to a customer needs an access design that accounts for that assignment. Do not assume selecting creator access will make a staff-created project available to its intended client.
Ask your developer to document the rule for each collection. For example: clients can read assigned project summaries, submit change requests, and read their own requests. Staff manage project status. That is a proposed workflow to implement and test, rather than a permission preset to select wholesale.
Wix's collection permissions overview also explains backend authorization suppression. If custom backend code bypasses collection permissions, the code must perform the necessary identity and access checks before returning data. Review that path explicitly during development.
Each client can access their assigned project and is denied access to the other project.
Define the data before designing the dashboard
For the two-client scenario, separate the customer's identity, the project, and requests about that project. This makes ownership and editing responsibilities easier to follow.
Record | Useful information | Decision to make |
|---|---|---|
Client relationship | Member account and customer or company reference | Can one company have several member accounts? |
Project | Customer reference, title, status and last update | Who can assign or reassign the customer? |
Change request | Project reference, submitting member, request and status | Which fields may the customer edit after submission? |
Staff note | Project reference and internal text | Which staff roles need access? |
A reference field connects records. Access checks decide whether the connection may be followed by a particular user. Keep both responsibilities clear in the specification.
If you are choosing how to structure repeated project pages, our static versus dynamic Wix pages guide covers the page-model decision. A reusable layout can simplify editing, while the access rules still need their own design.
Avoid collecting information just because there is space for it. List the fields required to complete the task, who uses them, and when they can be removed. For confidential file delivery, include direct file-link access in the review rather than assuming a restricted page protects every linked file.
Decide where custom Velo work earns its place
Custom development is useful when the portal needs rules that configuration alone does not cover. Examples include a customer accessing projects created by staff, several approved users sharing a company account's records, or a request that must be checked before changing a project.
Specify what should happen when a request fails. If the record was saved but an email failed, the client should not have to submit the same request again just to notify staff. Agree which system holds the saved request and how your team finds items that need attention.
For forms inside the portal, first compare the native options. New Wix Forms support conditional rules and multiple pages. Our Wix Forms versus custom Velo forms guide helps distinguish configuration work from a custom workflow.
There is also a practical buy-or-build decision. If a specialist portal product already covers your process, compare its access model, data export, ongoing fees and integration needs with a custom Wix build. Use the same task list for both options so the comparison stays meaningful.
Test with two ordinary client accounts
Wix notes that editor preview runs with admin access. Use the published test experience with ordinary member accounts and non-sensitive test records to check the client experience. Keep the test area isolated from real customer data.
Test | Expected outcome |
|---|---|
Signed out, open a restricted portal page | The visitor must sign in before entering |
Client A opens their assigned project | A sees the permitted project information |
Client B tries A's project URL or record ID | Access is refused without returning A's private data |
A attempts to change a staff-controlled field | The operation is rejected and stored data remains correct |
A submits the same request twice | Behaviour matches the agreed duplicate-handling rule |
Remove A's project assignment | A loses access on the next relevant request |
Submit on a phone using keyboard navigation | Labels, errors and confirmation remain usable |
The cross-account check matters even when the dashboard looks correct. Ask for evidence from the data-access path, alongside the visible screen. Testing only as the site owner can conceal permission errors because admins have broader access.
Include recovery tests too: a failed save, a slow response, an expired session and a notification that does not send. Each should leave the client with an understandable next action and your team with enough information to investigate.
Plan the handover and ongoing work
Agree who invites clients, assigns projects, removes access and handles a lost-login enquiry. Document which content staff can edit safely and which permission changes require developer review.
Ask for a proposal that separates the portal interface, data model, authorization, integrations, testing and maintenance. The number of dashboard cards is a poor measure of complexity. Sharing projects between several users can require more work than displaying many read-only fields.
CodeMasters' public Horse Tracker case study shows related work involving member accounts, records, reminders and document uploads. Those are useful capabilities to evaluate when discussing a portal, without assuming every portal needs the same features.
To discuss your scope, book a free 30-minute consultation. Bring your website URL, one client task, the records involved and who should be allowed to change them. We can discuss the implementation options and what needs further investigation before quoting. You can also send your requirements through our contact page.
Frequently asked questions
Can I build a Wix client portal without custom code?
Yes, when restricted pages and existing Wix features cover the client task. Start by listing the actions you need and checking them against the native options. Custom project records and company-level sharing need a more detailed access review.
Can every client see different information?
Yes, with an appropriate record-access design. Specify whether access follows the record's creator, an assigned member or a company relationship. Test with two separate customer accounts before using real data.
Does a members-only page protect the CMS collection?
Page access and collection access are separate controls. Review the collection permissions and any backend functions that return records. Check that another signed-in member cannot retrieve a customer's data.
What should the first portal release include?
Choose one complete task, such as viewing an assigned project's status and submitting a request. Include sign-in, access removal, mobile usability, error handling and staff handover in that release.
What determines the cost of a custom Wix portal?
The main scope decisions are the number of user types, record relationships, permitted actions, integrations and failure scenarios. Prepare a list of those requirements so a developer can quote defined work instead of an open-ended dashboard.
