Learn Mokapen

Main menu
Support Contact us

Client portal

The portal is the space where a client signs in with their own credentials, not with a Mokapen user. From there they open tickets, view orders and, if you enable it, the board. You keep working in the CRM: the ticket and the order are created in the pipelines you chose, with the owner you indicated.

You find it under Support → Portal. Each portal has its own address, in the form domain / language / portal / slug. The client does not see the rest of the organization.

 

Create the portal and keep it off until it is ready

From the list, press the button for a new portal. If the organization has already reached the maximum number, Mokapen opens the plan window instead of creating another one. On each portal card you see the title, logo, whether it is active or off, and the external link to the client home.

Under General you set the title, URL slug, default language, portal email and status. Active means the link responds. Inactive means the portal is unreachable: use it while you prepare pipelines, topics and catalog, so a client does not land on an empty page. The on-page wording is clear: you set up the portal and only enable the areas you want to show.

The portal email is the one the client sees as the sender of the credentials. If it is empty or is a mailbox nobody reads, access emails still go out but replies are lost.

 

Which areas the client sees

Under Applications you turn on, for this portal, the areas the client can interact with. There are three items, and not every organization sees them all:

  • Tickets — the client submits requests and reads the reply from there.
  • Orders — they see products and services in a catalog and submit purchase orders.
  • Board — appears only if the News app is active for the organization. It shows the board on the portal home.

Turning an area on is not enough. A portal with tickets on and no pipeline chosen creates requests you do not know where to find. A portal with orders on and without currency, pipeline and status leaves the order without a place in the sales pipeline.

 

Who can sign in

The portal Users page lists contacts already enabled: name, email, account, status, creation date and the privacy lock. It is a checklist, not the place where you create access. The filter at the top narrows the rows.

Access is granted from the contact card, Portal tab. The wording on the card says to enable the contact to access one or more portals of your organization, to communicate and receive support. For each portal there is a switch. When on, Mokapen creates a portal user for that contact and sends them an email with the credentials: you ask them to sign in and change the password. If you turn the switch off, the portal user is deleted. Orders and tickets already linked to the contact stay in the CRM.

On the same tab you choose visibility:

  • Private — the client sees their own tickets and orders.
  • Company — they also see tickets and orders linked to the same company. Use it for the contact person who must follow requests for the whole client, not for every person in the company: otherwise a salesperson sees tickets opened by a colleague.

Email, first name, last name and password are the portal login details. They are not the Mokapen user and do not inherit a CRM role. If you change email or password, the contact receives an update email.

A contact without an email cannot receive credentials. An archived or deleted contact disappears from the portal users list even if access had been turned on.

 

Tickets opened by the client

Under Tickets you choose the pipeline where requests land and the topics to offer. Topics are those already defined on that pipeline: if the list is empty, the client has nothing to select. The button on the page opens that pipeline’s topic settings, where you create them and, if needed, assign an owner to the topic.

The default owner receives every ticket born from the portal. On creation you can still assign them to another member. Without an owner, the request enters the pipeline and nobody sees it in their “my work” kanban until someone picks it up.

Once inside, the client sees their open tickets and can follow their status. They do not see internal tickets that are not linked to them (or, with Company visibility, to their company).

 

Orders from the catalog

Under Orders you prepare how the order is created when the client confirms the cart. You set currency, pipeline, initial status and owner. Title and description accept portal user variables: first name, last name, email, company, contact, note, privacy, language. A title like “Order from {first name} {last name}” stays readable in the pipeline; an empty title leaves you a row with no context.

In the portal the client browses the catalog, puts items in the cart and confirms. If the cart has products to ship, they are asked for the country for shipping costs. Taxes, VAT included, are calculated after confirmation. Once the order is created, the client receives updates and can follow it in their area.

With Company visibility the orders list also includes orders from the same company, not only those of the contact who signed in.

 

When the choice is wrong

  • Portal active before the applications. The client signs in and finds the home with neither tickets nor orders. Keep it inactive until pipelines, topics and owners are set.
  • Company visibility for everyone. Every contact in the company sees the others’ requests. Leave it for the contact person.
  • Same portal for clients who must not see each other. A portal is a URL. Data stays filtered by contact, but title, language and areas are shared. Two clients with different needs (tickets only, or tickets and catalog) are better on two portals.
  • Confusing portal user and Mokapen user. The first only enters the portal. The second works in the CRM and has a role. Giving the client a CRM Guest user is not the portal: they see internal cards, not the catalog.

Related guides: Tickets, Orders, Contacts.

Need help?