Making your end-user portal externally available can be a useful tool in allowing your customers to track their tickets and assets, easily see the services you offer them, and even use a knowledge base for your most frequently asked questions and issues from anywere.
There are a few steps to take before making the portal public, these are as follows:
Decide on a URL for your customers to access the portal.
Ensure you have access or can allow access to amend the DNS.
You have a valid SSL certificate for the domain you're implementing the portal to.
Your URL and Portal Installation
If you intend to leave the portal at its default location "https://yourwebappurl.com/portal" and your web-app is accessible from external locations and networks then you can skip this step and head straight to 'Turning on the New Portal'.
Picking a URL can be difficult, make sure it is succinct and descriptve. A URL such as https://support.yourcompanyname.com is a great choice as it outlines what they require, support, and who from, you!
With this change in URL a few extra steps are needed for configuration. These are outlined immediately below and attached as a word document. This will also be required to ensure continued continuity of service if you were previously using the older style portal associated with our windows client and are wishing to replace the old style portal with the new portal.
Changing the New Portal URL
Required steps should be as follows:
Copy appsettings.json from the root of the web app directory into the portal directory.
Set up a new site in IIS that points to the /portal directory and add a binding for the url you want it to have.
Stop the old portal site.
Tick the "use new portal field" on the Self Service Portal config page.
Change the url of the portal to the url of your new portal site.
Once chosen and registered with your registrar of choice then we can proceed to setting up a DNS record.
Adding a Record to your DNS for the Portal
Similarly to the above step if you're leaving the portal at its default location and the web-app is currently externally facing, then you can skip this step as the DNS records are already present.
Within your web hosting service you will have a list of records called your DNS records or register. This is a list of URLs that you either can modify their physical location of or a list of domains you can create subdomains within.
For self hosted web servers you will often use a proprietary hosting service with a DNS module or you may use the Microsoft DNS IPAM console for this. You can find a guide for this here.
Adding a record should be done in the same vain as previously has been done for your Web App and will follow a process similar to that linked above and involves inputting the domain which you're adding a record for, its server address, IP or FQDN if attached to an Active Directory already.
Adding an SSL Certificate
This is done within IIS and is a 4 step process:
Add the certificate to the server store by clicking into Server Certificates at the root level of IIS
Import the certificate, this should be done in PFX format and can be requested in that format from the certification authority.
When added head to the site and click into bindings in the top right of the window and click add binding.
Select HTTPS as 'Type:', Port 443 is the default HTTPS binding, add this as the HTTP binding and select the certificate. Click OK.
You now have an HTTPS binding on your portal site.
Turning on the New Portal
Head into your Web App and click into "Configuration > Self-Service Portal". Check the box to enable the portal. This will overwrite the portal URL on the self-service portal settings page and in organisation settings.
The next step is to browse to URL to check it's working, and if you're unable to navigate to this, you should contact your network administrator or call the Halo support team and we can assist where possible.
User access will need to be given to any users that will be logging into the portal. This can be configured on the user profile, under the Settings tab and Self Service Portal & API Settings subheading. There are several options for access:
Tickets the logged in user can access
No Access to the portal. The user cannot log in.
This User's Tickets
Only the tickets that are assigned to the user, and are visible to end users.
Tickets assigned to users under the same site that the logged in user exists in, and that are visible to end users.
Tickets assigned to users under the same customer/area that the logged in user exists in, and that are visible to end users.
Top Level Tickets
Tickets assigned to users under the same Top Level that the logged in user exists in, and that are visible to end users.
Tickets assigned to users within the same department as the logged in user, and that are visible to end users.
Site contact Tickets
Tickets assigned to users under sites for which the logged in user is a Site Contact.
The next step is to customise your user portal if you have not already done so, for which we have a guide entitled 'Self-Service Portal Customisation'.
If you have any queries regarding these settings, check out our other articles, or contact our support team and we can guide you on best practise.