I have a Account Relationship entity with two lookup fields called Recipient Account and Guide Account. I would like to be able to go on an Account and see all records where the Account Relationship's Recipient Account and Guide Account are set to the account I'm viewing.
In CRM, I can definitely create a view to fetch all account relationships on the Account Relationship entity and then inside the Account entity's form I can include the view with the data source set to Related Records Only and the entity set to Account Relationship (Recipient Account). But I can't do both in a single view.
Through what mechanism can I have it all be in one view? One thing I was considering was creating separate grids, one for Recipient Account and another for Guide Account. But I want to know if there is a mechanism where I can combine all records that have "Recipient Account = Current Account or Guide Account = Current Account" that is basically the query I want to run.
You could use connections. It's pretty flexible and will fulfill your needs as long they stay simple. That's the only viable option I see aside from using two views.
Keep only one subgrid of Account Relationship N:N intersect entity (either Guide account or Recipient account relation)
Register RetrieveMultiple pre-operation plugin to intercept the query & pass the custom fetchxml query by incorporating or filter
Fetchxml has to be built something like explained
Try this unrecommended if you wish but two grids are better choice. This alternate solution also you can try.
Related
I have created a custom entity in common data services(CDS) that streams in data from a survey.
I'll however need to give access to the data to various people. In my dataset, I have a column called community, which should represent which people have access to what data based on the community they've entered the column.
How exactly can I filter the data, after it has streamed in to ensure I only give access to people of a particular community. And yes every community is exclusive, no two people can be in two different communities.
I want to filter by the community, such that those in community A see only A and not B or C.
There’s no straight one step OOB configuration to achieve this. Because the row level security depends on the column value ie. community field value of each record.
One way is to create owner teams and add the users to right teams, then the custom entity record has to be owned by respective team - owner team of each custom entity record can be filled/assigned automatically based on the community field value on create using plugin/workflow/Flow.
Most important, in security role for that custom entity - read privilege has to be given only for user level. Assign the security role to Teams.
I have the below requirement -
We have an entity named Garden. A garden is owned by a person or company, and can also be leased by one or more people or companies. Each garden has a unique number.
Ideally, we would want to be able to see a single grid of all the people that own and/or lease the garden, regardless of whether they are a person or a company.
Questions -
1) Which entity to choose for person -> User or Contact
2) Which entity to choose for company?
3) How to design record ownership or leasing of garden?
This is a broad question, I’ll try my best.
Fact: We don’t have an option today to create a custom polymorphic entity - to capture/store multiple types of entities. There are some available OOB entities - Customer to store Account/Contact, Owner to store User/Team, Activity Regarding to store any Activity enabled entities.
If you look at Bookable Resource entity, even MS store the type like User or Equipment & respective lookup records separately. This is what you need exactly. Read more
1) Which entity to choose for person -> User or Contact
2) Which entity to choose for company?
User (owner) in case you need security around the ownership of the records. Then company has to be the Teams, because you mentioned Garden maybe owned by Person or Company. How many records you’re going to manage and are they going to get login in CRM?
You may have to look at PowerApps (Dynamics) portals which gives B2B, B2C options to control records ownership by Accounts/Contacts.
3) How to design record ownership or leasing of garden?
Partially answered in the above points. For leasing, you can have multiple subgrid (1:N) relationship. If required, you may need a custom component or web resource to pull the multiple type of owned/leasing records by UNION the results & render as a grid.
For the accounts entity I have different account types.
However I need to make some of these records read only only based on the account type, as these records will be slaved in CRM.
However the user should still have ability to create other types of accounts that will be mastered in CRM.
I was thinking to do this via security role however when giving create or edit permission on the account entity user can still create accounts of any type or edit existing slaved data.
What would be the best way to make slaved data read only?
Use business rules to lock all fields based on the type?
Like you said, this cannot be achieved with security role, since the requirement is based on a field value.
Disabling all the form fields in bulk - You can do this in javascript quickly, or may be with Business rules one by one. Verify the field value on form load for your certain slaved value account type, then disable the controls by iterating each one of them.
Still subgrid, webresource, iframes will be editable.
In CRM Online I need to link the Account Name field in the Account entity to a lookup table of imported and approved company names. The goal is to require users to pick from an approved list instead of letting them make up a company account name. I know there is an Account Name lookup in Contacts which uses existing Account Name records, but I need the lookup in the Account entity. Thanks for any tips.
If you are referring to a different entity as LookupTable, then create a relationship between Account ans the Lookup Table entity. After that you can use that entity as Lookup attribute in Account entity
CRM renders a Lookup control for a 1:N relationship. What you are trying achieve would fall more into a data validation scenario where users can enter account names from a pre-set list of names.
You can leverage a new event introduced in CRM 2016 - addOnKeyPress which can be easily used to build an autocomplete feature which would be more inline with what you are trying to achieve. If a user doesn't "pick" a value instead types anything in disregarding the autocomplete use attribute control's setNotification to set an error message which would invalidate the save preventing the user from saving the record.
I'm new to CRM, and am having difficulties implementing a subgrid onto an account form. I am not a programmer.
I will not bore you with the methods that I have tried to so far; that could take a while. Suffice it to say, I am having no luck.
i have created and imported two sets of records from my SQL database. One set was imported into the standard Accounts entity and the other was imported into a custom entity; let's just call that it Problems.
The relationship between Accounts to Problems is one-to-many. Each Account has a "problemID" and each related Problem has a "problemID" as well.
I need to be able to place a subgrid containing all related Problems onto the Accounts forms. I need to be able to see the old ones and create new ones.
How would YOU handle this?
Many thanks!
For a 1:N relationship between Accounts and Problems you only need a lookup to the Account Entity on the Problem entity. Then you can:
Edit the Account Form
Insert a Sub-grid
Set the sub-grid to look to "Only Related Records" for "Problems"