2. Plug-In deployment Options and why?
The 3 storage options are: Database, Disk and GAC. The main differences between these are:
· Database: The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once if you have multiple CRM servers, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in a production environment
· Disk: The assembly dll is placed in the \server\bin\assembly directory on each server. You have to ensure the dll is placed in the correct place on all CRM servers, so the deployment overhead is a little greater. I normally use this option in development environments as you can redeploy newer versions solely by file transfer, rather than reregistering. Also, if debugging, the assembly .pdb file needs to be placed in the same location; with this option it’s easy to ensure the dll and pdb are from the same build
· GAC: The assembly is placed in the Global Assembly Cache on each CRM server, and again you will have to do this. The GAC does allow multiple versions of an assembly, but CRM doesn’t, so you don’t really gain anything by using the GAC.
3. Secure / UnSecure in Plug-In
Following are the two key differences found between these two configuration settings.
|
Unsecure Configuration
|
Secure Configuration
|
|
Unsecure configuration information could be read by any user in CRM. Remember its public information (Ex: Parameter strings to be used in plugin could be supplied here)
|
The Secure Configuration information could be read only by CRM Administrators.(Eg: Restricted data from normal user could be supplied here)
|
|
Imagine that you include a plugin, plugin steps and activate them in a solution. Later solution was exported as Managed Solution to another environment. In this scenario, the supplied unsecure configuration values would be available in the new environment.
|
The plugin with secure configuration in a solution was exported as Managed Solution to another environment. In this scenario, the supplied secure configuration information would NOT be available in the new environment. The simple reason behind this is to provide more security to the contents of Secure Configuration
|
· Access
o Data passed through “Unsecure” section is PUBLIC (i.e., It can be read by any user in CRM).
o Only users with “System Administrator” role have access to the data passed through “Secure” configuration section
· Storage
§ Only “System Administrator” has Read access on this entity, hence only users with ‘Sys Admin’ role can access this data
o Both “Secured & Unsecured” configuration data stored as “Plain text” in DB
o “Unsecured” configuration data is downloaded to the user’s computer when they go offline making it Unsecure
o “Secured” configuration data is NOT downloaded to User’s Computer when they go Offline
6, Can be extended more by using PowerShell script
Refer the below link for more information
http://inventcrm.wordpress.com/2013/09/05/changing-maximum-number-of-controls-on-dashboards/
Code based security is entirely coded in the application itself. Role based security uses one of the authentication/authorization mechanisms of the application server. The fundamental concept in role-based security is that of privilege, defined at design time, on a system-wide basis. Each user has a set of privileges (there are well over a hundred privileges) that are enabled for that user. However, Policies and Roles grant privileges and simplify the process. The other form of security applies to individual instances of objects. There is a fundamental difference between an access right and a privilege: an access right is a right granted to a user on an object), but a privilege is a right granted to a user on a class of objects. Access rights apply only after privileges have taken effect. In other words, if a user does not have the privilege to read accounts, the user will not be able to read any account, whether or not it has been shared.
Find perform a search on an attribute for which it is defined. Advanced Find perform search on the conditions and the attributes for which user customizes or runs it. Normal Find in faster as it looks for one attributes and matches with that and returns the result whereas Advanced Find searches for all the attributes and conditions while parsing through the records. Find is applicable on only active records and it finds only on 2 or 3 column which we have defined in the find view and even it returns any those column which is there in the view but advanced find is applicable to all the records and it finds all the columns and even it returns all the column and filter criteria can be on any column and most important – find filters on just one condition but advanced find filters on multiple condition at one time.. Find is faster than Advanced Find.
Deployment Web Service, Discovery Web service, IOrganization Service.
Asynchronous Plugin
a) Plugin has maximum time limit of 2 minutes. Plugin running synchronously will get timed out after 2 minutes.
b) We can configure plugin to run as (another) user’s context.
c) Cannot accept any input parameters, by default it takes only details from the entity using IPluginExecutionContext.
a) Assembly does not have maximum time limit. It is preferred when consuming external webservices in the plugin.
b) Cannot configure with Run as (another) user’s context.
c) Can accept input parameters and return output parameter to workflow. Can be configured to run as a child workflow while plugin does not have this feature.
MSCRM_CONFIG, ORGNAME_MSCRM
‘Append’ and ‘Append To’ privileges works together. ‘Append To’ privilege will allow other entities to get attached with the entity. ‘Append’ privilege will allow the entity to attach the records to the entity with ‘Append To’ privilege.
Let us say that you want to attach a note to a case then note entity should have ‘Append’ access right and case entity should have ‘Append To’ access right. Let us take one more example to understand this. Suppose you have two custom entities called ‘TestCustomEntity1’ and ‘TestCustomEntity2’. You want to attach the ‘TestCustomeEntity2’ records to ‘TestCustomEntity1’records. For this you need to have ‘Append’ access right on ‘TestCustomEntity1’ entity and ‘Append To’ access right on ‘TestCustomEntity2’.Now guess will I be able to attach the records? Answer is “NO” because we need to create a 1:N relationship between ‘TestCustomEntity1’ and ‘TestCustomEntity2’. Now the user who has above mentioned access right in his security role will only be able to add ‘TestCustomEntity2’ records to ‘TestCustomEntity1’.
Using Dynamic Entity in CRM 4.0 and Entity in 2011.
Using Linked entity.
No, we will have to re-install MSCRM
In my experience, marketing is somewhat of a new concept in CRM. Sales are definitely involved, but most often it is operations leading the charge.
Officially max 8 tabs, unofficially we can do plenty (It’s not recommended by Microsoft CRM)
Unmanaged Solutions
All solutions start out as Unmanaged. When it is in the unmanaged state, you can add, remove, update, and test any of the components of the solution. You can delete components of your unmanaged solutions, while leaving it available for use in the rest of the system. Some on the MS CRM Dev team have likened this to your ‘source’ code of your system. The great thing about an Unmanaged Solution is that during development, you can create restrictions (like ‘not customizable’) on the components as they evolve.
When your unmanaged solution is ready for the show, you simply export it to ‘Managed’. You could think of this as ‘compiling’ you code. You set the restrictions (i.e. prevent customizations on certain components) and the end user lives by those rules. But remember, they can still customize the components of the solution that are unrestricted. You cannot add or remove components of a solution, even if the component is unmanaged.
Once you have packaged the Managed Solution, it can be installed into another organization. They can also be deployed across multiple deployment types (Online, Partner Hosted, On-Premise) and all CRM Clients (web, Outlook, Mobile Express, and Offline via Outlook Client).
Refer the below links for more information
SQL database views, called “filtered views,” are provided with the Microsoft CRM database to enable access to business data according to the user’s Microsoft CRM security role. When a user runs a report that obtains data from filtered views, the user’s Microsoft CRM security role determines the data to be included in the report. Data in filtered views is restricted at three levels: the organization, the business unit, and the owner. Filtered views exist for all Microsoft CRM business objects (entities).
SELECT * FROM dbo.FilteredAccount
|
Event
|
Stage Name
|
Stage Number
|
Description
|
|
Pre-Event
|
Pre-validation
|
10
|
Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage may execute outside the database transaction.
|
|
Pre-Event
|
Pre-operation
|
20
|
Stage in the pipeline for plug-ins that are to execute before the main system operation. Plug-ins registered in this stage are executed within the database transaction.
|
|
Post-Event
|
Post-operation
|
40
|
Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage are executed within the database transaction.
|
|
Post-Event
|
Post-operation
|
50
|
Stage in the pipeline for plug-ins which are to execute after the main operation. Plug-ins registered in this stage may execute outside the database transaction. This stage only supports Microsoft Dynamics CRM 4.0 based plug-ins.
|
PreEntityImages
It is basically used to capture the data when the form loads. That is the data which is present by default when the form loads
PostEntityImages:
The Post Image contains the attributes value which are finally changed. We can capture the changed data before the database operation takes place. And can do any kind of validation based on the changed data. Remember it can only be registered for update message and cannot be registered on create message.
21. How you will make sure your CRM application is fast and not having performance issue?
http://support.microsoft.com/kb/968520
The POA table is used to provide access to specific records for CRM users, and each record in the POA table represents one CRM object that is related to one CRM user. Records created in the POA table come from one of four ways:
If this is set to Yes, then records would be added to the POA table whenever an assign takes place. These records will have a value in the AccessRightsMask column of the POA table.
Reparent Setting: Relationship Behavior
Each entity has relationships with other entities (ex. Account to Case). By default, the Reparent option is set to Cascade All. With this setting, sub records would be shared to the owner of the parent record. For example: Let’s say that User1 owns Account1. User2 has access to Account1 and creates a case underneath Account1. With the out of the box Reparent options, a record would be created in the POA table that would give User1 access to the newly created case. These records will have a value in the InheritedAccessRightsMask column of the POA table.
When sharing occurs through a direct share, assignment, or parenting, if the relationship is set up to cascade the share to child records, additional records will be created in the POA table in order to give proper permissions to the new user for the relevant child records. These records will have a value in the InheritedAccessRightsMask column of the POA table.
24. What are different activities available in CRM?
c. Appointment
d. Meeting
e. Email
f. Letter
g. Fax
i. Service Activity
By creating entity Ownership as Organization. Product is one of the CRM out of the box entity with ownership as Organization.
Yes, We can. Export the chart, modify the XML and then import it.
27. Workflow Ownership…. And workflow types.
29. Early binding VS Late Binding?
Early Binding
Compiler bind the objects to methods at the compile time. This is called early binding or static binding. Function overloading is example for early binding.
Late Binding
Compiler bind the objects to methods at the runtime. This is called late binding or dynamic binding. Function overriding is example for late binding.
//Early binding
Account account = new Account();
account.Name = “Via Context”;
service.Create(account);
//Late binding
Entity objEntity = new Entity(“account”);
objEntity [“name”] = “Via Service”;
service.Create(objEntity);
30. What is publisher? Prefix and Option value prefix.
Publishers in Dynamics CRM are organizations that develop custom solutions. A publisher can include an organization that makes their own solutions for internal usage or third-party developers who re-sell their solutions. Prior to making changes to Dynamics CRM for the first time, you should edit the default publisher. For most organizations, this one-time edit of the default publisher is all that should be required. If, however, you plan to republish your customizations and provide them to other organizations, then you may want to create a publisher specifically for that purpose. Some larger organizations may wish to create publishers based on different business units or even different individual developers.
Name:This value cannot be changed. For most organizations this will not present a problem.
However, if you plan to make your solutions available to others and you want to create a unique name that aligns better with your company branding, then you will want to create a new publisher for this purpose.
Prefix:This small field is the most important one on the form. It permanently impacts every customization you make to Dynamics CRM using this publisher. Every component (entity, field, and so on) that you create in Dynamics CRM will be prefixed with this value. The value will only show up in views available to administrators and developers. Although this value can be changed later, components created with this value permanently retain it — so select a value that you don’t plan to change. This is usually a three- to five-letter acronym that your organization may be known for. The prefix makes it fairly easy to identify customizations that your team made to Dynamics CRM versus changes that may have been made by others.
http://support.microsoft.com/kb/2778280
http://garethtuckercrm.com/2011/01/18/how-to-view-ribbon-definitions-in-crm-2011-3/
http://msdn.microsoft.com/en-us/library/bb955303.aspx\
http://msdn.microsoft.com/en-us/library/bb955303.aspx\
37. How you Create N:N Relationship?
39. How you create a security role?
Yes, we can create it.
41. What all new feature you know about 2013.
43. What is the Difference between Stage and Step?
45. What kind of entities you can use while creating BPF?
47. Is the BPF works and useful in Real time scenarios? If yes How?
