(v2.0)
GET or SET Field Value Using JavaScript At the time of writing of this post, there are two possible way to access fields in Dynamics 365/CRM that are on the form. That way will depend on what version of Dynamics 365/CRM you are using.
Overview
This simple JavaScript library allows you to easily call workflows, dialogs, and actions in CRM from forms, views, web resources, or anywhere that supports JavaScript. This solution works in CRM 2013, CRM 2016, and everything in between, including CRM Online and CRM 2016 Update 1.0. (Also in my opinion easier to use and better than Web Api is currently).
In the past if you've needed to call a workflow or action from JavaScript, you need to build a massive XML SOAP request making sure to pass in the correct attributes and conditions to get the request working.
This is tedious and messy, especially when there are many places you need to do this in a solution. It's also not good if something breaks in the future and you need to go back and fix up all instances of where the code is being used.
For these reasons, I've created this library to simplify calling processes, and to make the code manageable going forward. But most of all, it's so I don't have to keep finding the correct way to build the SOAP requests!
For completeness, I've also included a function for calling dialogs, which simply pops open the specified dialog.
Make sure to add a reference to the process.js code library on your form or ribbon.
Check out the Documentation for more detailed usage information.
Call Action
Calls the specified action and returns the response from the action asynchronously. Useful when needing to run C# code from web resources or command bar buttons when only JavaScript is available.
You can also kind of call the CRM 'actions' such as create and update by specifying the action name as 'Create' or 'Update', and the pass in the correct input parameters, i.e. an Entity object called 'Target'. While this does appear to work, I'm not supporting such calls, so please stick to custom actions if you want it to work in future :)
Parameters: Action Unique Name, Input Parameters (array), Success Callback (function), Error Callback (function), CRM Base URL (not required on forms/views)
Each Input Parameter object should contain key, value, and type. Types are defined by Process.Type enum. EntityReference values should be an object containing id and entityType.
To assist with creating EntityReference and Entity objects, use the build in Process.EntityReference and Process.Entity types, e.g.: var entity = new Process.Entity('account', '{guid}'); entity.attributes['fieldname'] = 'Some value';
The Success Callback function should accept 1 argument which is an object containing the output parameters. E.g. to access the 'OutputParam1' value, use: var value = params['OutputParam1']. If the output param type is Entity or EntityReference, the 'value' will be of those types, allowing you to access properties like: value.id. EntityCollections will simply be an array of Entity objects.
Access fields from an entity object using: value.attributes['fieldname'].value (check for null first), or use the extension method: value.get('fieldname') to handle the null check itself. Access formatted values for certain field types using: value.formattedValues['fieldname'].
Check out Process.js Extensions for pre-made sample Actions which can be used with Process.js to get you started.
Usage:
Call Workflow
Runs the specified workflow for a particular record asynchronously. Optionally, you can add callback functions which will fire when the workflow has been executed successfully or if it fails.
Parameters: Workflow ID/Guid, Record ID/Guid, Success Callback (function), Error Callback (function), CRM Base URL (not required on forms/views)
Usage:
Call Dialog
Note: This function has been deprecated. It will remain in the solution, however no future enhancements or fixes will be done. Please check out Alert.js for a better way of showing dialogs.
Opens the specified dialog for a particular record in a CRM light-box, or Modal Dialog if run from Outlook. Once the dialog is closed, a custom callback function can be executed, e.g. to refresh the form with new data set by the dialog.
Parameters: Dialog ID/Guid, Entity Name, Record ID/Guid, Callback function, CRM Base URL (not required on forms/views)
Usage:
Created by Paul Nieuwelaar - @paulnz1
Sponsored by Magnetism Solutions - Dynamics CRM Specialists
-->Sponsored by Magnetism Solutions - Dynamics CRM Specialists
Record-based security in Dynamics 365 for Customer Engagement apps applies to individual records. It is provided by using access rights.
The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if a user does not have the privilege to read accounts, that user is unable to read any account, regardless of the access rights another user might grant to a specific account through sharing.
Access rights
An access right is granted to a user for a particular record. The following table lists the descriptions for these access rights.
Access right | AccessRights enumeration value | Description |
---|---|---|
Read | ReadAccess | Controls whether the user can read a record. |
Write | WriteAccess | Controls whether the user can update a record. |
Assign | AssignAccess | Controls whether the user can assign a record to another user. |
Append | AppendAccess | Controls whether the user can attach another record to the specified record. The Append and Append To access rights work in combination. Every time that a user attaches one record to another, the user must have both rights. For example, when you attach a note to a case, you must have the Append access right on the note and the Append To access right on the case for the operation to work. |
Append To | AppendToAccess | Controls whether the user can append the record in question to another record. The Append and Append To access rights work in combination. For more information, see the description for Append. |
Share | ShareAccess | Controls whether the user can share a record with another user or team. Sharing gives another user access to a record. For more information, see Sharing Records. |
Delete | DeleteAccess | Controls whether the user can delete a record. |
Create access
The right to create a record for an entity type is not included in the previous table because this right does not apply to an individual record, but instead to a class of entities. Create is handled as a privilege instead of as an access right. The user who creates a record has all rights on that record, unless his or her other privileges forbid a specific right.
The Create privilege controls whether you can create a record. If you have the Create privilege with Local, Deep, or Global access, you can create records for other users. If you have Create and Read privileges with Basic access, you can create records for yourself.
For more information about dependencies that relate to create privileges, see Dependencies between access rights.
Sharing records
Sharing lets users give other users or teams access to specific customer information. This is useful for sharing information with users in roles that have only the Basic access level. For example, in an organization that gives salespeople Basic read and write access to accounts, a salesperson can share an opportunity with another salesperson so that they can both track the progress of an important sale.
For security reasons, develop the practice of sharing only the necessary records with the smallest set of users possible. Only grant the minimum access required for users to do their jobs.
Dynamics 365 for Customer Engagement apps provides the following sharing capabilities:
- Share. Any user who has share privileges on a given entity type can share records of that type with any other user or team in Dynamics 365 for Customer Engagement apps. To share a record, use GrantAccessRequest.When you share a record with another user, indicate what access rights (Read, Write, Delete, Append, Assign, and Share) you want to grant to the other user. Access rights on a shared record can be different for each user with whom the record is shared. However, you cannot give a user any rights that he or she would not have for that type of entity, based on the role assigned to that user. For example, if a user does not have Read privileges on accounts and you share an account with that user, the user will be unable to see that account.
- Modify share. You can modify the rights granted to a shared record after it has been shared. To modify sharing for a record, use the ModifyAccessRequest.
- Remove share. If you share a record with another user or team, you can stop sharing the record. After you remove sharing for a record, the other user or team loses access rights to the record. To remove sharing for a record, use the RevokeAccessRequest.
Tip
Use GrantAccessRequest, ModifyAccessRequest, and RevokeAccessRequest for sharing.
A user might have access to the same record in more than one context. For example, a user might share a record directly with specific access rights, and he or she might also be on a team in which the same record is shared with different access rights. In this case, the access rights that this user has on the record are the union of all the rights.
For a list of entities that support sharing, see the GrantAccessRequest.
Sharing and inheritance
If a record is created and the parent record has certain sharing properties, the new record inherits those properties. For example, Joe and Mike are working on a high priority lead. Joe creates a new lead and two activities, shares the lead with Mike, and selects cascade sharing. Mike makes a telephone call and sends an email regarding the new lead. Joe sees that Mike has contacted the company two times, so he does not make another call.
Sharing is maintained on individual records. A record inherits the sharing properties from its parent and also maintains its own sharing properties. Therefore, a record can have two sets of sharing properties—one that it has on its own and one that it inherits from its parent.
Removing the share of a parent record removes the sharing properties of objects (records) that it inherited from the parent. That is, all users who previously had visibility into this record no longer have visibility. Child objects still could be shared to some of these users if they were shared individually, not from the parent record.
Assigning records
Anyone with Assign privileges on a record can assign that record to another user. When a record is assigned, the new user or team becomes the owner of the record and its related records. The original user or team loses ownership of the record, but automatically shares it with the new owner.
In Dynamics 365 for Customer Engagement apps, the system administrator can decide for an organization whether records should be shared with previous owners or not after the assign operation. If Share with previous owner is selected, then the previous owner shares the record with all access rights after the assign operation. Otherwise, the previous owner does not share the record and may not have access to the record, depending on his or her privileges. The
Organization.ShareRoPreviousOwnerOnAssign
attribute controls this setting.For a list of entities that support Assign, see the AssignRequest.
Retrieving the access rights for a record
Use the RetrievePrincipalAccessRequest message to retrieve the access rights the specified security principal (user or team) has to a record.
Use the RetrieveSharedPrincipalsAndAccessRequest message to retrieves all the security principals (users or teams) that have access to a record, together with their access rights to that record.
Dependencies between access rights
Sometimes, security dependencies exist because it is necessary to have more than one access right to perform a given action. For example, if you have the create access right for accounts, you can create a record of the account entity type. However, unless you also have read access for accounts, you cannot create an account record and be the owner of that new record.
The following table lists the access right dependencies for the actions specified.
Action | Access rights required |
---|---|
To Create a record and be the record owner | CREATE READ |
To Share a record | SHARE. This right is required by the person doing the share operation. READ. This right is required by the person doing the share operation and also by the person with whom the record is being shared. |
To Assign a record | ASSIGN WRITE READ |
To Append To a record | WRITE READ APPENDTO |
To Append a record | WRITE READ APPEND |
Another type of dependency exists when objects are subordinate to another object. For example, the opportunity object cannot exist on its own. Each opportunity is always attached to an account or contact. To create an opportunity, you must have the access right appendto on accounts and the access right append on opportunities.
See also
The Security Model of Microsoft Dynamics 365 for Customer Engagement apps
How role-based security can be used to control access to entities in Microsoft Dynamics 365 for Customer Engagement appsHow field security can be used to control access to field values in Microsoft Dynamics 365 for Customer Engagement apps
Introduction to Entities in Microsoft Dynamics 365 for Customer Engagement apps
Entity Relationship Behavior
AccessRights
RetrievePrincipalAccessRequest
How role-based security can be used to control access to entities in Microsoft Dynamics 365 for Customer Engagement appsHow field security can be used to control access to field values in Microsoft Dynamics 365 for Customer Engagement apps
Introduction to Entities in Microsoft Dynamics 365 for Customer Engagement apps
Entity Relationship Behavior
AccessRights
RetrievePrincipalAccessRequest