299 Friday, May 27, 2016 |
Msxrmtools Publisher
Publisher at Msxrmtools

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:

  1. 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.
  1. 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.

Microsoft Dynamics CRM: Manually Entering a Lead

[Job] - Microsoft Dynamics CRM, India

Company: Accenture

Location: Hyderabad, India

Job description

Role:- Developer

Years of experience:- 3 to 4 years

Must to have:-

  •  Must have worked on CRM 011
  •  Must have worked on Dynamics CRM 4 or 011 version
  •  Should be able to create and debug Plugins - Should be able to create and debug Custom Workflow activities
  •  Should be able to do Ribbon customization - Understanding of Solutions - Understanding of the security in Dynamics CRM
  •  Should have understanding of using Developer Toolkit for Dynamics CRM

Good to have:

  •  Exp in Silverlight - SSRS
  •  Strong design and development skills
  •  Ability to design and develop flows
  •  Effectively communicates to internal and external stake-holders"


Basic qualifications

Full Time Graduation

Sales Literature: Create Sales Literature

The Sales Literature area provides a way to add, remove, and manage documents associated with products and services.

To create sales literature in Microsoft Dynamics CRM, follow these steps:

  • On the Navigation Bar, click Sales and then click Sales Literature.
  • In the Command Bar, click New.
  • In the General section of the form, enter the following information as appropriate and observe any noted restrictions or requirements as needed:
    • Title: This is a required field.
    • Subject: Type the subject or click the Lookup button and select the subject. If no subjects are listed, select Default Subject. This is a required field.
    • Type: Select from the drop-down list.
    • Employee contact
    • Expiration Date
    • Description: Type any detailed information that must be highlighted in the sales literature.
  • In the Command Bar click SAVE.

Associate Records In Microsoft Dynamics CRM Using Early Bound

Associate Method

To associte records in Microsoft Dynamics CRM use IOrganizationService.Associate(entityName, Guid, Relationship, EntityReferenceCollection) method.

Parameters

Name Type Comment
entityname String Entity logical name
guid Guid The ID of the record to which the related records are associated.
relationship Guid The name of the relationship to be used to create the link.
relatedEntities Guid A collection of entity references (references to records) to be associated..

Output

Void

This method is implemented by OrganizationService class and OrganizationServiceContext generated in previous chapter.

Using Early Bound 

Following example demonstarates how to associate a contact with three accounts in Microsoft Dynamics CRM using early bound

C#

// Associate the accounts to the contact record.

// Create a collection of the entities that will be 
// associated to the contact.
EntityReferenceCollection relatedEntities = new EntityReferenceCollection();
relatedEntities.Add(new EntityReference(Account.EntityLogicalName, _account1Id));
relatedEntities.Add(new EntityReference(Account.EntityLogicalName, _account2Id));
relatedEntities.Add(new EntityReference(Account.EntityLogicalName, _account3Id));

// Create an object that defines the relationship between the contact and account.
Relationship relationship = new Relationship("account_primary_contact");


//Associate the contact with the 3 accounts.
_service.Associate(Contact.EntityLogicalName, _contactId, relationship,
    relatedEntities);

Console.WriteLine("The entities have been associated.");

//Disassociate the records.
_service.Disassociate(Contact.EntityLogicalName, _contactId, relationship,
    relatedEntities);

Lead Management: Lead To Opportunity Process Ribbon contd.

  • Close
    • Complete Final Proposal
    • Present Final Proposal
    • Confirm Decision Date
    • Send Thank You
    • Final De-brief

Manage your field service workforce with Dynamics CRM

Watch this video to learn what field service capabilities for Microsoft Dynamics CRM can do for your organization. Field service capabilties are now built in to CRM. We’ll show you how field service delivers advanced scheduling, inventory tracking, and asset management for service depots. And how it helps highly mobile, in-field specialists fulfill work orders and provide preventive maintenance across multiple sites under complex service agreements.

What Areas where we can write JavaScript?

We can use JavaScript to perform actions in form scripts, ribbon commands and web resources.

Microsoft Dynamics CRM 2011: Implementing Claims and IFD: Part 6

This session will cover some common troubleshooting questions related to Claims-Based Authentication and IFD in Microsoft Dynamics CRM.

 

Upgrading from Microsoft Dynamics CRM 2013 to 2015

Retrieve Records In Dynamics CRM Using QueryByAttribute

Following example demonstrates how to retrieve records in dynamics crm using QueryByAttribute.

Connection string

<connectionStrings>
<add name="connection" connectionString="Url=https://org.crm.dynamics.com; Username=user@org.onmicrosoft.com; Password=password;"/>
</connectionStrings>

 C#

using Microsoft.Xrm.Client;
using Microsoft.Xrm.Client.Services;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace CrmSampleCodes
{
public class QueryByAttributeSample
{
IOrganizationService _service;
public QueryByAttributeSample()
{
_service = new OrganizationService("connection");
}

public void Run()
{
// Create query using QueryByAttribute.
QueryByAttribute querybyattribute = new QueryByAttribute("account");
querybyattribute.ColumnSet = new ColumnSet("name", "address1_city", "emailaddress1");

// Attribute to query.
querybyattribute.Attributes.AddRange("address1_city");

// Value of queried attribute to return.
querybyattribute.Values.AddRange("Redmond");

// Query passed to service proxy.
EntityCollection retrieved = _service.RetrieveMultiple(querybyattribute);

System.Console.WriteLine("Query Using QueryByAttribute");
System.Console.WriteLine("===============================");

// Iterate through returned collection.
foreach (var c in retrieved.Entities)
{
System.Console.WriteLine("Name: " + c.Attributes["name"]);

if (c.Attributes.Contains("address1_city"))
System.Console.WriteLine("Address: " + c.Attributes["address1_city"]);

if (c.Attributes.Contains("emailaddress1"))
System.Console.WriteLine("E-mail: " + c.Attributes["emailaddress1"]);
}
System.Console.WriteLine("===============================");

}
}
}

Color Grid for Dynamics 365

Color Form for Dynamics 365