Portals or Roles for third party access to specific data

[davide445]

We want to allow some partners to verify if there is already an Account managed from the internal sales team, so to avoid unnecessary superimpositions. They will need to see only the account name and info and the assigned internal user, but no other related data (i.e. no Stream, Opportunities, Contacts, Activities).
Was wondering if a better approach might be to use Portals (since they are a different company), or just define a different role (i.e. Sales Channel) with specific access control (so i.e. in Layout Manager set a rule to hide all the panes with the unnecessary info for this specific Role).
What's the best practice for using portals?

[Maximus]

Hi David.
I believe the Portal is exactly what you need here. Just specify the restrictions in Role for the undesired fields to prevent your customer from being able to read them.

[davide445]

Maximus I have done some tests and what I didn't get is how regular users data interact with portal users one.
As example I just created a portal so to allow my external collaborator on a project to look at tasks I will create and control Cases I will also generate.
I have created his portal user and his role restricted only to Cases and Tasks, but didn't get how my user will be able to interact with this portal.
I added my user to the portal but I'm unable to login, also creating a case I didn't find a way to assign it to the specific Portal, so how is supposed to work the data sharing between regular and portal users.

[Maximus]

1. Portal is not separated from the main CRM system environment. It is just the same CRM but with a very tiny scope of access provided to the portal users. So when your portal user creates a Case entry, for example, the Case entry is available for the regular user as well.
The main thing here is the portal user has no ability to assign created record to any of your system users. So if your regular CRM user has only 'own' scope permission to Read the record, he won't be able to see the created by a portal user Case.
So if your regular CRM user has only 'own' permission in the scope to read the record, he won't be able to see the created by a portal user Case.
To avoid this you need to define some logic that will auto-assigns an entry created by the portal user to your system user. For example, it can be achieved with Formula. If you have Advanced Pack than you can utilize Workflow and set Assignment rule with different conditions.

2. Portal created for your customer only. It is wrong trying to create a portal user from your system user. The system user might have a much more privilege to get access to data and other functions.

[davide445]

Maximus more testing and can't find the sweet spot for portal usage.
For a development project team needining to work to specific tasks and solve specific issues:
My portal user didn't have access to anything except Cases and Tasks based on Account access control, since he will need to work on the elements I give him. His user is associated to a single Account.
On my side using my standard user I tried to create a task and a case associated (Parented to) with this Account.
The portal user can see them, but as example can't edit the Case status, fundamental since the need to work on them and next set them as solved.

Also as another use case: I need external users to query the complete account list showing only basic data (they are sales agents, needing to verify if an account is already worked on from someone), but so far I need to explicitly associate a portal user to some specific account list or contact list. In this way he will not be able to view all the accounts. If I set the portal role to view all, I didn't have in the Acount Layouts the opportunity to hide some details (i.e. Bottom Panels>Contacts) based on Teams, since the portal user didn't belong to any team.

[Maximus]

1. By default a portal user cannot edit some fields (e.g. Status field in Case). But you can allow him to do that by giving him the edit permission for the Status field in the field level of a portal user's role (see screenshot).

2. The second scenario you described is not supported. You need either create for such external user a regular user in the system with a very tiny scope of access or rewrite the source code in order to allow portal users have access to the desired scope of data.

[davide445]

Thanks for this.
Since I suppose also case 1 can be managed in the same way as case 2, returning a bit on the more general question, what's the case where using Portals is really a benefit respect standard Teams/Roles?