The built-in Dynamics CRM 2011 Activities report is a pretty good report. It's even better if exposed on a dashboard, which I show you how to do in this recording, which is an excerpt from the June session of my Dynamics CRM 2011 Essentials series.
Early Bound Programming in Microsoft Dynamics CRM
Early-Bound: In early-bound programming type-checking and binding happens at compile time.
Early Bound Programming in Microsoft Dynamics CRM
In Microsoft Dynamic CRM, the code generation tool (CrmSvcUtil, available in SDK) generates strongly-typed classes for early-bound programming. These classes can be used in applications that use Microsoft Dynamics CRM as well as plug-ins and custom workflow activities.
Generated classes include all entities, attributes and relationships.
Each time you make customizations to your system, you must regenerate these classes.
Advantages of early-bound programming
All type references are checked at compile time.
Much faster development as compared to late-bound.
Intellisense support in Visual Studio.
Disadvantages of early-bound programming
Early-bound classes needs to be regenerated, each time you customize your system.
Slightly slow performance as compared to late-bound.
Early-bound classes are wrapper to late-bound classes because of this serialization costs increases as these entities are converted to late bound types during transmission over the network.
This performance difference is extremely small and can be neglected.
Sales representatives can use quotes to inform potential customers about the products and prices associated with a sales opportunity.
Quotes cannot be saved unless a price list is specified.
[Job] - Microsoft Dynamics CRM Consultant, United Kingdom
IBM Hiring for Microsoft Dynamics CRM Consultant
Location: Any City, United Kingdom
Business process analysis, requirements capture, design and product configuration skills that have been proven within enterprise level clients.
A self starter with the ability to work within an operating framework.
Willing to work across our European practice and client sites
Ability to identify and analyze business and functional requirements.
Ability to design solutions based on the Dynamics CRM platform.
Demonstrate the ability to configure CRM.
Other skills required:
Good presentation skills.
Excellent communication skills both written and verbal.
Ability to prepare and deliver solution training (Admin, end user)
Experience of the following configuration processes:
Workflow Entities & relationships
Form design Business process flows
General system administration
Security roles Deployment processes
Please note, the base locations for this role are: Southbank (London), Manchester, Warwick or Hursley.
Microsoft Dynamics CRM 2013 for Tablets - Customizations
Microsoft Dynamics CRM 2011 Outlook Client Installation & Configuration troubleshooting
Microsoft Dynamics CRM: Quick Campagins
Simplify case resolution with the Dynamics CRM interactive service hub
Pull customer information from one central place to resolve cases quickly with the Dynamics CRM interactive service hub. This video provides an overview of the interactive service hub, and shows how you'll spend less time looking for the information you need to resolve customer issues, and more time focusing on your customers.
Deliver projects on time and on budget with Dynamics CRM
Project service in Microsoft Dynamics CRM empowers your organization to deliver project-based engagements on time and on budget. What can you do with CRM project service? Estimate, quote, and contract work. Plan and assign resources. Capture time, expense, and progress data for real-time insights and accurate invoicing. And lots more!
Processes/Workflow Ownership Mystery in Microsoft Dynamics CRM
Under what user’s context does the workflow execute? (If the workflow creates a record, who will be the owner of that new record?)
It depends. Automatically triggered workflows (such as a workflow that triggers on account create) will execute in the context of the owner of the workflow. Therefore, if you have a send email step, the email will be by default sent from the e-mail account of the workflow owner. This is important to consider because the workflow owner might belong to a different business unit and have different privileges than the user who triggered the workflow (e.g. who created the account). Let’s say your workflow creates a task each time an account is created. Depending on the privileges of the user, the task might be in another business unit and not visible to the user, therefore you should consider adding an “assign step” that assigns the new task to the owner of the account. Now, if the workflow is executed on-demand, the workflow will then execute in the context of the user who requests the workflow execution. Because dialogs are always on-demand then they always execute in the context of the user who started the dialog.
Why does the process execute under different users depending on how it was started?
This was a design decision based on security considerations. You don’t want to inadvertently be sending emails and executing actions without knowing it because some other user decided it. Therefore, by having this different behavior we can guarantee that the user under which the workflow executes is always aware that a workflow is performing some actions on his behalf. For the automatic workflow case, the owner of the workflow is also the person who activates it and who selects the trigger mechanism and the workflow steps so it is OK if the workflow executes under that user’s context. For the on-demand case, a user is specifically requesting some actions to be performed on his behalf by a workflow so the user is fully aware of the workflow definition and that it will execute; therefore it is safe to execute the workflow under that user’s context instead of the workflow owner (who might not be aware that a user requests an on-demand execution).
Why can’t I activate/deactivate someone else’s workflow, even if I am the system administrator?
For the same security reason as explained above. You want the workflow owner to explicitly acknowledge that a workflow will be activated and will perform some actions on his behalf. You would not want to allow another user (even the system administrator) to decide that some process should be executed on another user’s behalf. If you want to activate/deactivate someone else’s process you must first assign it to yourself.
If I assign an activated process to another user, why does the user have to re-activate it?
Active processes cannot be modified so the system automatically deactivates them before assigning it to the new user. As per Q3 above, only the new owner will be able to re-activate the process.
I am importing a solution that contains processes and it fails with this error message “The workflow cannot be published or unpublished by someone who is not its owner”. What is wrong?
If your solution contains a process that already exists in the organization and is activated then solution import will attempt to update it. In order to do so, it must first deactivate it. However, if the owner of the activated process is not the same as the user who is importing the solution, then deactivating the process will fail (see Q3). Therefore you have a few options to fix this problem:
Import the solution using the user who owns the activated process. This can be tricky, especially if there are multiple processes owned by different users which need to be updated by the solution import.
Verify which processes are included in the solution, and then find them in the organization, if you can find them and they are not owned by you then you must assign them to yourself. You can reassign them to the original user after you import the solution; however, you will have to ask the process owners to activate it themselves.