Domain Aliases for EspoCRM Portal URLs

[marcusquinn]

I'm setting this up now and just founds that the custom EspoCRM Portal URLs won't work as we don't have domain aliases but only redirects.

As an example, with a root URL of crm.example.com I want to setup Portal URLs:

• clients.example.com
• staff.example.com
• accounts.example.com

Quite a pressing need, anything we can do to help make this happen?

[girish]

Good time to bring it up. I am trying to see if I can implement it for 6.1, so I went looking for the docs and found https://docs.espocrm.com/administration/portal/. I think it will work with what I am implementing as per https://forum.cloudron.io/topic/3191/domain-aliases/29 . I don't have an "immediate" fix. What I can do is once I push the patch, I can post a link and you can apply it on your server. Otherwise, 6.1 should be out next week. We were hoping to release last week but some of the translators require some time to finish.

[marcusquinn]

@girish Cool!

Just in time as I managed to get myself locked-out when setting up portals on the main domain and logging in with the same browser session instead of a new private window or separate browser

I can live without a week if it's in the pipeline, I'll just refrain from battle-testing my setups until then.

---

As a side note, from what I've found so-far with EspoCRM is that I both really like it, and I feel better offering a client support portal with it for centralising and de-duplicating data and functionality than having Freescout as well.

IMHO, if one has EspoCRM, you don't need a Heldesk as well. If one has another CRM that doesn't have a helpdesk, then maybe.

Trying to work with less apps nowadays, having been down the road of a large team with too many separate apps. Life's too short!

[girish]

@marcusquinn I have made a new package v1.16.0 which should support this now. https://docs.cloudron.io/apps/espocrm/#portals has the docs. Let me know how it works.

[marcusquinn]

@girish Works perfectly - thank you so much!!

For anyone else following this thread and app - Portals are a killer feature - get to know how they work, they will add massive value to partner communications!

For interest, the way permissions management works in EspoCRM

• "Roles" you set all the permissions for what users with that Role cannot see, so opt-out permissions.
  "Portal Roles" you set all the permissions for what users with that Portal Role can see, so opt-in. Which is very fast to setup.

Example use-case;

1. Create an Entity called "Brand Assets", add some multi-attachment fields for things like Icons, Logos, Fonts, Banners, Biographies, etc.
2. Create a Portal called "Marketing" with the custom URL as marketing.example.com.
3. Create Portal Role for "Marketing" with access to the " Brand Assets" Entity, and maybe some others once you get used to permissions sharing.

Hey-presto! Your own live data sharing portal for that Entity. Once you've done one, you have a model for all external partnership types to share Entities and all or some records for their access to the latest single source of truth.

Here's some more ideas I'm modelling Portals for:

[timconsidine]

@girish said in Domain Aliases for EspoCRM Portal URLs:

https://docs.espocrm.com/administration/portal/

I'm really interested in this feature. But my head is screwed up on scope.
Before I dive in to configuring in detail and breaking things ...

Do I understand correctly :

• setting up Alias in Cloudron allows access on different (sub-)domain, but the app data is basically same on main and each alias : same users/logins, same contacts data, no segregation. So if I have crm.companyONE.com and crm.companyTWO.com, the contacts are the same across both 'companies'.
  Interesting but I don't understand the 'use case' for this.

• combining Cloudron alia with EspoCRM portal and portal users and portal roles would allow different url, different users/logins, different view on data according to permissioned portal roles. While all the contact data is in a single database environment (so no actual data segregation), there is apparent segregation. companyONE user cannot see companyTWO contacts etc.

If true, this can be neat technical implementation.

If I want real data/system separation, can I set up TWO EspoCRM apps in Cloudron ?
This is not neat technically, but maybe is more resilient.
Advice appreciated.
Many thanks.

[marcusquinn]

@timconsidine understandings all correct. Portals are a very useful feature too and well worth trying/having.

You can't break anything as far as I can tell, just setup the aliases in your Cloudron EspoCRM App Location, and the same in EspoCRM Portals. Eg:

(note, you don't need to add the https:// at the beginning)

You could use main domains as well, I'm just building this out as a demo/template system first.

[timconsidine]

@marcusquinn Very helpful, thank you

[girish]

@marcusquinn not sure if you know but you can put *.brandlight.org as an alias if you want instead of adding each one inside Cloudron dashboard (as in, you can put wildcard in alias but only as subdomain). nginx matching of server_name is such that it gives explicit server_name a priority, this means that if you install an app later, then it will get precedence.

[marcusquinn]

@girish Nice, didn't know that but handy!

I think if using other multi-subdomain apps like WP Multi-Site on the same Cloudron it could get confused but agree, that's a simpler way if only using one of them. Thanks