InoLink: QuickBooks - Dynamics CRM Integration Version 2.0 Released

We have come up with the next version of InoLink: QuickBooks - Dynamics CRM Integration

InoLink: QuickBooks is an integration link developed to integrate QuickBooks with Dynamics CRM. After detailed evaluation of the feedback received over a period of time we have come up with this version.

What’s new in this version?

1. The general look and feel has been vastly improved for seamless integration with Dynamics CRM.

2. Better user experience in terms of use of Ajax for user feedback to processes.

3. Additional feature added to the Promote Account functionality to support the Alternate Contact and multiple address feature of QuickBooks.

4. Ability to unlink existing linked accounts from Dynamics CRM to QuickBooks in case you want to no longer link the two records.

5. It now supports import of QuickBooks product types such as Inventory, Non-Inventory, Services, Other Charges, Inventory Assembly products.

6. Huge changes in the Sales Order/Invoice promote functionality to account for the discount and tax calculations.

7. Ability to associate discount with Discount type of Line items in QuickBooks so that they are taken over to QuickBooks correctly.

8. Once an account is linked to a customer in QuickBooks, ability to calculate tax of the order/invoice based on the Tax % in QuickBooks has been provided.

9. Closes the Sales Order in QuickBooks when an invoice associated with it has been promoted from CRM. This makes sure that promoting invoices from CRM does not leave the Sales Order in QB open.

For detailed information on the features of InoLink: QuickBooks Dynamics CRM Integration click here

Sharing access in Dynamics CRM

Dynamics CRM has the concept of record ownership. A record can only be owned by single user and not by a team or more than one users. Depending on the security roles defined it is possible to restrict a user to have access to only records owned by them.

However in most practical situation where people work in teams it would be required to allow a group of persons to have access to certain records in addition to the records owned by them. In such case you can use the concept of “Sharing” that is available in Dynamics CRM. Note when you share a record with a group you are only making the record accessible to them and for all other purposes the owner is still the original user and a single user at that.

To share records, first select the records you want to share. On the Actions toolbar, click More Actions, and then click Sharing. As shown in the below screenshot.





When you share a record, you can define the level of permission that you would like to provide the other users with whom you wish to share the record.



Now in the above screen a record has been shared with Brian giving him all permission to the record except delete. This enables Brian to be able to view this record in the Active Records view and also update the record or create activities for this record.

However Anton can only see the record in his active view. But when he open the record it will be available in read-only mode and he would not be able to make any changes to this record.

Programmatically the sharing is controlled by SecurityPrincipal object. To get a list of users/teams with which a record has been shared you will need to use the RetrieveSharedPrincipalsAndAccess message. This message needs to be provided with the TargetOwned Class. If you provide an instance of an account to this message. It will return an array of PrincipalAccess class that will list out all the users/teams and the level of access of each of these on the entity provided. This message can be excuted using the Execute method of the CRM service class.

Other messages to look out for are
GrantAccessRequest
ModifyAccessRequest
RetrievePrincipalAccessRequest

-------------------------------------------------------
Posted by: Inogic
For more information/discussions (documents, sample code snippets, detailed work flow or diagrams),
Please be free to visit the following links or email us:
Web: http://www.inogic.com
Blog: http://inogic.blogspot.com
Email: news@inogic.com
-----------------------------------------------------

CRM Relationship Behavior (contd) - Cascading rule for Relationship Behavior

We had written on CRM Entity Relationships in one of our earlier post on this blog. To take this further today we would like to discuss the way the settings for the Cascading Rules affect the related entities when an action is performed on the main entity.

Cascading Rules:

Following action can be taken on the parent entity
- Assign
- Delete
- Merge
- Reparent
- Share
- Unshare
The cascading rules let you decide the action to be taken on the child entities when any of the above action is taken on the Parent. This helps you decide how to handle the child entities and if you want them to behave differently than the parent entity.

Say suppose you want Delete the parent entity, what action should be taken for the related child entities. Ideally you may want the child to be deleted along with the parent. But sometimes you may want it otherwise. You want to keep the child entities and delete the association with the Parent. You can define this using the cascading rules.

The following options are available.

Cascade All:
Perform the action on the primary entity as well as related entity.
e.g. if an account is assign to another user from current user then all its related contact will get assigned to the new user.

Cascade None:
Perform the action on the primary entity but not on the related entity.
e.g. if we delete a contact and do not want to delete the activity related to the contact, use Cascade None.

Cascade Active:
Perform the action on the primary entity. Also it performs the action on related entities which are active or open.
e.g. If we delete an account from CRM, using this rule we can avoid the deletion of related invoice and orders.

Cascade User-Owned:
Perform the action on the primary entity. It performs the action on cascade entity only if the related entity has same owner as that of the primary entity.
e.g. We can delete all the contacts related to an account which have the same owner and leave others untouched using this rule.

Remove Link:
Perform the action on the primary entity and remove the link of related entity. Do not perform any action on the related entity.
e.g. If we want to just delete the account and remove the link of account from contact, we can use this rule.

Restrict:
Perform the action only and only if no related entity exists. If any related entity exists the action is cancelled. This rule is applied on “Delete” action only.
e.g. If we don’t want to allow user to delete an account having any contact then we can use this rule to disallow user from performing “Delete” operation.

Understanding the way the relationships work goes a long way in working with Dynamics CRM. It helps you provide simple solutions to seemingly tough tasks.

-------------------------------------------------------
Posted by: Inogic
For more information/discussions (documents, sample code snippets, detailed work flow or diagrams),
Please be free to visit the following links or email us:
Web: http://www.inogic.com
Blog: http://inogic.blogspot.com
Email: news@inogic.com
-----------------------------------------------------

InoDashboard – Dynamics CRM Business Intelligence Dashboard released

Dynamics CRM requires a comprehensive tool for monitoring the KPI in a visual/dashboard format. Inogic labs has come up with InoDashboard, a Business Intelligence Dashboard designed for Microsoft Dynamics CRM to fill in this gap. This tool will allow the CRM users at each level to design a dashboard specific to them and include the reports and monitor areas specific to their interest.

It comes along with a pre-packaged bundle of about 40+ reports that provide you with the most commonly requested reports for monitoring the KPI. Whats more is that with the wizard kind of UI it is very easy to develop your own custom reports/charts with basic knowledge of writing SQL queries. The Dashboard can be seen as below screen shot.

Its feature set includes

• Easy to create reports to analyze your CRM data.
• No learning curve required. Use your SQL query writing skills to design reports.
  
• Ability to add CRM reports, views, custom website URL
• User personalization available.
• Secured reports. Pre-defined reports use Filtered Views to force inbuilt CRM security.
• Ability to drill down to CRM entity forms.

Technical details

• It is developed using .NET Chart control for designing the various charts
• It makes extensive use of Web parts to support personalization
• It supports the following types of charts shown in the screen shot.

It supports Dynamics CRM 4.0 On-premise with IFD

We have come up with this after a lot of research in this area some of our r n d was put up in our earlier blogs http://inogic.blogspot.com/search/label/Dashboards where we studied the various ways in which a dashboard could be presented in Dynamics CRM.

Increasing the length of address1_line1 attribute does not work - FIX

We once happened to increase the length of the adress1_line1 attribute of account to 200. We had done this before with other attributes and it had worked just fine.

So we were surprised when even after publishing the account entity after make the above change, we still received an error.

To Fix this Error we had to instead increase the length of line1 attribute of the “customeraddress” entity and publish this entity.

Once the above change was published we did not receive any more errors related to street1 attribute on the account entity.