I'm evaluating CRM 2011 to replace an existing app and and have some questions about security and segregating information by Client (or Account).
I have a custom entity for 'Client'. There are lot of custom entities that are related to 'Client' which consitute the data needed to be captured.
I would like to limit specific teams/users to work on specific clients and see only the data for those clients that they have access to.
I'm seeing that individual entities can be assigned to teams/users but I need all related entities to be locked down by Client so that regular users
Dont see records in views or searches that belong to other clients.
Can't create or access records for other clients.
Can this be done in CRM 2011? How?
Also - is it possible to limit processes/workflows to operate or trigger on records of specific clients only?
Probably the easiest thing to do would be do base your security on business units. Groups of clients an their related records would all be in the same business unit, and as long as you set their security roles to only allow access to records in their own business unit, that would work.
For workflows that only trigger on particular clients, it depends on the exact requirements. You could certainly check the business unit of the client as the first step in the workflow and continue or exit based on that. If it's something more complex, you can write a custom workflow assembly to do the check for you.
Related
i'm trying to learn Microservices by implementing a sample project, tried to pick a semi-complex one to face real world challenges in Microservice architecture.
this is a simplified version of the project flow that I designed till here:
the flow
as you can see in the image I'm trying to get the list of appointments for a specific company, but since the required data is inside different Microservices, for getting the appointments I have to follow these steps:
the API gateway (bff) will get the request from frontend that contains a token
bff will authorize the jwt token by sending it to the users ms
appointments are separated by companies ids, so before getting the appointments, I need to get the user company
company id will be sent to appointments to get the appointments for the company
appointments will check to see if actor is authorized to get the list of appointments by its role (came earlier from the user ms)
appointments will return the list of appointments
inside appointments as you can see in the entities, I do have the id of both sides (sideA, sideB)
bff will get those users details by the ids from users
inside appointments data that is returned, there is a customer_id that is the id of a customer inside the company ms so bff send another request to the company to get the customer details
inside customer details, there is an id of a project that the customer is eager to visit so, bff will send a request to get the project from the projects ms
at the end, bff will join the data and return it to the frontend application.
this is also the simplified version of entities inside Microservices:
entities
right now, i'm using composition API approach to get the data I need, but as you can see the flow is complicated, and I can't think of a way to implement pagination, since I might need to sort, filter and then paginate the data, so I think in this situation, this might be a good idea to use CQRS pattern, but the problem is since I have many situations like this, I have to implement lots of CQRS services.
I'm wondering if:
is it possible to create a single CQRS service to have all the data for read purpose, instead of CQRS for each situation?
for some situations like this, the CQRS read database will becomes almost identical to a monolith architecture db. is. this okay?!
is there any alternative way to scape the complexity of creating and managing multiple CQRSs with partial repetitive data?
CQRS will help you get all the required details in one call. A CQRS service will have multiple tables that are part of different microservices.
An example will be like "OrderViewService" will require to listen and store events from "OrderService", "DeliveryService", "AccountingService". But it wont be listening to multiple other services which are not of concern for "OrderViewService".
So the point I am making here is the database won't become so similar to the monolithic database as it would have a lot more details.
For your project you might require a single CQRS that may deliver your requirements.
As it seems your requirements have dependency on all of the microservices and so a single CQRS service could help you solve the requirements.
Also if you are concerned about the space make sure what details would be required were only be saved to the view/read CQRS database. Thereby ensuring that we are not overwhelming the db with all the details from all the services.
As application grows there can be multiple CQRS services listening to different services or a combination of services and thereby serving their responsibilities.
Reference - https://microservices.io/patterns/data/cqrs.html
I think this explains and these are my thoughts about CQRS. Let me know if you have any questions post it as comments.
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
We recently faced an issue with Process entity privilege which could well be a design problem in Dynamics CRM itself. Or may be we're doing something we're not supposed to.
As you all know Process is a common entity for new Custom Action feature and the original Workflows. We used a few custom actions in the system to improve form load performance and make some processes transaction aware.
The problem is that users need organization level read access on Process entity to make a call to these custom actions which is ridiculous. There was a requirement for users to have limited access to workflows but since the custom actions and workflows share the same privilege through Process entity, this is impossible to fulfill.
For server side custom pages and plugins we can impersonate as a privileged user but most of these custom actions are being called from JavaScript (we used it to speed up form load by aggregating queries into single web service call)
Is there a way we can limit users access to workflow and still be able to let them call custom actions?
Another question is that are custom actions not meant to be used in this way? Which, if no, would makes custom actions quite useless.
Thanks in advance!
I've been told a few times that Business Units in CRM 2011 are "tricky" and shouldn't be set up lightly since they have irreversible consequences for a CRM 2011 implementation.
On the other hand, teams in CRM 2011 seem much more flexible in managing record security.
For what reason would I still choose to set up Business Units in CRM 2011? What can I do with Business Units that I can't with Teams (and vice versa)?
Business Units are important for the security concept of Dynamics CRM. They define a kind of a boundary within you can define specific roles or permissions. They are also used to represent an organization structure.
Teams are used for ownership of a record (new feature in CRM 2011), which is handy if you can't define a single owner. They are also used for easier sharing - you could share a record with a team, instead of sharing it with multiple persons. Another usage is to grant permissions to multiple users with grouping them into a team and assign a security role to the team.
Create a separate, new Business Unit (BU) at a higher BU level than all of the other User BUs (to avoid security role Parent:Child Business Unit permissions), then create a Team in that Business Unit.
Next, assign a security role to the new Team. Set the security role to be
restricted Read at the BU level (half a pie). Then, assign the "special" records to the Team.
Next, put the people who you want to see the records into the Team.
They will inherit the Team's security role permissions and will be the only ones in the company that can see those specific records.
You don't necessarily have to assign records to the team if you can just assign them to a user in that BU. However, you may need to assign the records to the Team if you don't have a user in the BU.
**NOTE: Watch out for Parent: Child Business Unit or Organization level permissions. The BU hiearchy would then play a role here.
*Be sure to test this before you put this into production**
Please follow below links which help alot
http://andrewbschultz.com/2011/08/09/business-units-bus-and-security-roles-in-microsoft-dynamics-crm-2011-solution-exports/
http://andrewbschultz.com/2011/06/17/the-architecture-of-team-security-in-crm-2011/
Thanks,
Is there a way to track user activity in Microsft Dynamics CRM? The end result would be a list of users, showing a datetime for each access into CRM, and possibly what modules are being accessed.
Also, is there a way to tie users to database connections, as is done in AX?
Why do you want to do this? The reason I ask is because there are many different ways to log user access depening on purpose.
Detailed access logging can be performed by IIS (web log).
Logons are also tracked in the Event Log->Security log.
Changes to entities can be tracked by implementing an audit log using workflows (or buying a third party component to do this).
The third option is to write a .NET plugin that logs whatever you want on whatever event you want on the entities you choose. Lookup plugins in the Microsoft CRM SDK for more information on how to do this.