The following steps that you can follow if you did not know is to be able to override the price per product on your order products in Dynamics CRM.

You will need to grant access to the person who is creating the order by going to Settings => Security => Security Roles => Sales as per the following screenshot,

On the Products Grid, Don’t click on the Product Name or on the Price Per Unit Boxes, click on any empty space on the item row (example like the red box below).

This will open you another window where you can edit the product price. Edit the price then click the  Save icon on the bottom right and go back to the order from the recent opened tabs. You will see the changes have been reflected.

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

Imagine that on the case entity, you have created a custom button on the ribbon “Create New Article”.

If you accessed your CRM Organization using the IFD URL and clicked on the “Create New Article” button out of the context of the case record, then the ribbon bar on the new article form didn’t appear.
If you accessed the Organization using Internal URL then the ribbon got loaded.

Why does this happen?

This happens in situations in which the function responsible for the Create New Article button had following structure:
function CreateNewArticle() {
var serverUrl = Xrm.Page.context.getServerUrl();
var kbarticletemplateId = '{C3F93721-91B6-475A-ACD0-0A68AA1CB842}';
var url = "";
url = serverUrl + "/main.aspx?etn=kbarticle&extraqs=_CreateFromId%3d%26_CreateFromType%3d%26_tmplid=" + kbarticletemplateId + "%26etc%3d127&pagetype=entityrecord";
window.open(url, null, 'width=900,height=750,location=no,toolbar=no,status=yes,resizable=yes', false);
}

The cause is that when you use the Xrm.Page.context.getServerUrl() method, this will return following:

1. For IFD, you get following URL format:
https://OrganizationName.DomainName.com/
2. While, when retrieving an Internal URL (http or https) the format is the following:
http(s)://CRMServerName.Domain.Com/OrganizationName

Based on the above, if we access the CRM Organization using the IFD URL then “/main” is appended to the https://OrganizationName.DomainName.com/ and it results in https://OrganizationName.DomainName.com//main and it is failing.

What can we do to solve this problem?

To work around this, you can modify the script to identify which URL we are using. This will check if the URL is for IFD or Internal URL. This is based on the fact that we know that if we access the CRM Organization using the IFD URL, this will contain the OrganizationName right after https://, .We can then extract it and compare with the actual OrganizationName. If they match, then we know that we are accessing CRM via IFD and we need to change the URL accordingly. If they don’t match then we know that we don’t access CRM via IFD and there is no need to change the URL.

The resulting code would be something similar to this. You can find in yellow the most relevant parts of the applied workaround:

function CreateNewArticle() {
var serverUrl = Xrm.Page.context.getServerUrl();
var organizationName = Xrm.Page.context.getOrgUniqueName();
var kbarticletemplateId = '{C3F93721-91B6-475A-ACD0-0A68AA1CB842}';
var url = "";
//We will use the tempServerUrl variable to see if we are accessing the CRM Organization via IFD or via the Internal URL
//when we access the CRM Organization via IFD the URL format is https://CRMOrganizationName.domain.com:
//what we can do to see if we are accessing via IFD or not is to get the CRMOrganizationName from the Url returned by Xrm.Page.context.getServerUrl()
//and compare it to the actual organization name returned by Xrm.Page.context.getOrgUniqueName();
//If they match, then we know that we are accessing the CRM Organization via IFD and not via the Internal URL or via http
var tempServerUrl = "";
//We remove the first 8 characters (https://) from the Server URL so from "https://CRMOrganizationName.domain.com:", we will have "CRMOrganizationName.domain.com:"
//this will not affect the http connection as the http url has 7 characters https:// instead of 8 https://
tempServerUrl = serverUrl.substring(8, serverUrl.length);
//Then we check for the organizationName length and and keep the number of characters from the tempServerUrl matching the number of characters in the organizationName
//so we will have from "CRMOrganizationName.domain.com:" only "CRMOrganizationName"
tempServerUrl = tempServerUrl.substring(0, organizationName.length);
//We set them both to lower case so that we can compare them
tempServerUrl = tempServerUrl.toLowerCase();
organizationName = organizationName.toLowerCase();
//we then compare them.
//if these strings match, then we know we are using IFD and we build the URL accordingly -> we remove the extra '/' which is added by Xrm.Page.context.getServerUrl()
if (tempServerUrl == organizationName) {
serverUrl = serverUrl.substring(0, serverUrl.length - 1);
}
//else we keep the URL untouched.
url = serverUrl + "/main.aspx?etn=kbarticle&extraqs=_CreateFromId%3d%26_CreateFromType%3d%26_tmplid=" + kbarticletemplateId + "%26etc%3d127&pagetype=entityrecord";
window.open(url, null, 'width=900,height=750,location=no,toolbar=no,status=yes,resizable=yes', false);
}

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

This article is to explain about Project Services trial or buying, including guidance for Existing Trial Customers.

As of July 6th, Trial editions for Project Service Automation are installed through CRMOL Settings > "Dynamics Marketplace" or Microsoft AppSource (link below).

Step 1:

Go to the marketplace and find ‘Trial for Project Service Automation’ solution

https://appsource.microsoft.com/en-us/marketplace?product=dynamics-crm

Review the application information and click on the “Try” button. You must also to provide credentials (the same ones that you use to connect to the CRM Online organization)

Alternatively, you can go into your Dynamics CRM Online instance and go to Settings > Dynamics Marketplace to get to the below list of apps.

Step 2:

Select the target instance on which to install the Trial solution and agree to the Terms of Service and Privacy statement.

This will take the user to the CRM Online Admin Center “Manage your solutions” page.

STEP 3:

Wait for the “Trial for Project Service Automation” installation to go from “Installation pending” to “Installed”

Step 4:

Then you can go to the CRM Online instance to access the new Project Services installed via the CRM Menu.

Existing Customer Trial Updates

If you have already installed a Trial for Project Services, then this provisioning model change will remove the line entry from their “Manage your solutions” view in the CRM Admin Portal.

To get updates for a Trial edition of the solution, you need to follow the above process to install the “latest” edition of the Trial package on at least one instance in your tenant.

This will make the Trial for Project Services package visible again in the “Manage your solutions” view and will make updates available for other instances with an installation of the trial solution.

Buying the CRM Project Services solution

There are 2 situations we are facing at the moment:

1. SANDBOX: - CANNOT INSTALL PAYED VERSION ONLY TRIAL

To use it here, you should Access to CRM Sandbox > Go to Settings > Customizations > Dynamics Marketplace, you will find Trial for Project Service and Field Service and you should just click on "Try" and the installation begins

The only prerequisite is to have CRM 2016 Service Pack 1 installed.

2. PRODUCTION

You need to firstly buy the solutions and after that, you will be able to access them. In order to buy them, you should either request support from the Billing department or get in touch with a TAM (Technical Adviser Manager) or SAM (Account Manager).

The recommendation will be to firstly UNINSTALL IT from Manage your Solutions on the Office 365 Portal, buy it, install it again. After the install is over, you should be able to see it like in the below image:

If you do not uninstall it first, then it is still going to show as trial but it will be the paid one if you purchased it.

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

This article is to publicise one interesting component in Dynamics CRM that probably not everybody is aware of. It is the XRMServiceToolkit

This is in essence a Javascript library that can help us do certain tasks more easily and quickly; for instance, tasks like CRUD (Create, Update, etc.) via REST and SOAP among other things.

It is important to note, that it is only available for CRM 2011, 2013 and 2015. You can use it for CRM 2016, by pointing to the old /XRMServices/2011/Organization.svc endpoint. The developers are considering extending the support to v2016, but a final decision hasn’t been made as of yet.

As an example of its usage, we can use this code to create a record:

var contact = {};

contact.FirstName = "Diane";

contact.LastName = "Morgan";

contact.MiddleName = "<&>";

contact.GenderCode = { Value: 2 };

contact.CreditLimit = { Value: "2.00" };

contact.BirthDate = birthDate;

contact.DoNotEMail = true;

contact.DoNotPhone = true;

XrmServiceToolkit.Rest.Create(

                contact,

                "ContactSet",

                function (result) {

                               contactId = result.ContactId;

                },

                function (error) {

                               alert(error.message);

                },

                false

);

As you can see, it reduces the length and complexity of the code that would be needed in case of not using the toolkit.

In order to use it, the following steps are needed:

1. Download it from the site referenced above, and extract its contents.
2. Create a new web resource in CRM called “JQuery”, Select the ‘Script(JScript)’ as the Type, and then browse for the jQuery.js file that you extracted.
3. Create two more web resources called “json” and “XRMServiceToolKit”, by repeating the step ‘4’.
4. Add all these web resources to a form in the following order:
   i. jQuery
   ii. jSon
   iii.XrmServiceToolkit
   iv.Your web resource library

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

This article is regarding CRM 2016 On Premise claim based enabled and SharePoint 2013 On Premise with server-based authentication integration, and CRM users are unable to create SharePoint folders and get  401-Unauthorized error.

After having configured the server-based authentication for the integration between CRM2016 On Premise with claim based enabled and SharePoint 2013 On Premise by following this technical article https://technet.microsoft.com/en-us/library/dn949332.aspx, the CRM user will receive an error from SharePoint saying that he is not authorized to create a SharePoint folder.

This can affect also if a CRM user has administrative privileges on both CRM and SharePoint.

The complete error description received by SharePoint while performing the action, is:

"Authorization Failure - The remote server returned 401 unauthorized error. Please contact your administrator. "

<errorlog><sites>

               <site>

                      <url>https://intranet.ufs.ac.za/sites/crm</url>

                      <exception>The remote server returned an error: (401) Unauthorized.</exception>

<errorcode>-2147088204</errorcode>

                      <correlation>0568719d-b0d5-90f6-c44e-ee933c5728fa</correlation>

</site>

        </sites></errorlog>  

As a note, SPS does not need to be configured for ADFS.

The cause of this is when CRM 2016 is claims enabled, then the SharePoint 2013 (that was integrated with the server-based authentication method) expects that CRM sends the SharePointEmailAddress attribute value with a value equal to the value that the same ActiveDirectory user has in its Workemail attribute in the SharePoint user profile.

Because this value is taken from the ActiveDirectory Account email attribute or ProxyEmail attribute, on CRM of the CRM user SharePointEmailAddress attribute should be populated with a consistent value.

However, because the mapping of the attributes between Active Directory and SharePoint user profiles can be changed manually or automatically on a SharePoint side (depending on how the SharePoint 2013 is configured, this means that there could be different way on how to populate properly the value for the SharePointEmailAddress attribute (for example a CRM workflow that is triggered when the emailaddress of the CRM user is modified, then it goes to populate with the same value the SharePointemailAddress).

Workaround

As a preamble:

On the SharePoint side, be sure that the CRMuser ActiveDirecotry account is part of the site members to allow the creation of the document library and SharePoint folders from CRM, and also that for the same user, the work email attribute in his profile is exact the same of the attribute SharePointEmailAddress for the CRM user.

In case of you cannot see the WorkEmail attribute on the SharePoint user profile have a look at the communication section of this blog https://sharepointobservations.wordpress.com/2013/07/16/error-you-do-not-have-an-email-address/

On CRM side, be sure that when provisioning the CRM user, double check that the SharePoint Email Address attribute of the CRM user is populated with the same value of the Work Email attribute of the SharePoint user.

Note: for the same ActiveDirectory user, in case of the value of the SharePoint work email attribute or the value of the CRM SharePoint Email Address attribute are not matching, then the 401 error will appear.

As a side note on how to apply the workaround, since it depends on the specific scenario and how it is working the sync between ActiveDirectory users and the SharePoint user profiles, we can do the following on CRM:

- Customize the system user main form on the CRM, to add the sharepointemailaddress attribute on the form

- Publish All

- Locate the CRM users under settings, and open the CRM user form

- Locate the added attribute and fill in the email address value (this need to be exactly the same value that the same related AD user has in SharePoint for the work email attribute in its profile)

For example:

- We have in AD the user user1, where it’s email is user1@localserver.com

- We add the user to the CRM org, so the CRM user user1 will get the primaryemail address equal to user1@localserver.com because it is taken from AD

- On SPS, the same user was added, and (in the OOB scenario) the work email attribute is equal to user1@localserver.com as well, because it is taken from AD

Remark: a remote far situation, but that can happen is that if the customer goes to AD and modify the emailaddress for user1, and then the AD-SPS user profile sync job run and apply the new value on the work email attribute for the user1 in SPS, the customer need to go also on CRM, edit the CRM user1 user information, and update the SharePointemailaddress attribute to maintain the match.

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

You may come across an issue when you have an option set, but the options are not displayed as a dropdown.

If spacers are added to the section where the option sets control is located, the dropdown will display correctly.

For a specific scenario, option Sets when placed at bottom of a form only display two values. 

Note:  These Option Sets contains more than 2 values.

This is a By design limitation of the specific scenario stated.

With the current design of CRM, the opened option set is already using the maximum space available in the tab to display the options.

The tab's height is very small because it only has one field in it (just one control that is the Option Sets) and even if we increased the opened option set’s default/minimum height, you would not even be able to see the additional options because the options do not overflow outside of the tab. 

To reproduce this:

1. Create an option set.
a. Click on Microsoft Dynamics CRM → Settings → Customizations → Customize the system
b. Then expand Entities (under components) → expand Accounts → Forms → Accounts (Main) → New Field
c. Enter the mandatory details
d. Select the type as option set
e. Click on the “+” sign
f. Enter “Item 1” to "Item 9" under the Label
g. Click on the description field
h. Click on save and close
2. Now open the account form and in the command bar click on the FORM button to customize the form.
3. Go to the insert tab in the form customization, and insert a new tab with 3 Columns for example at the very end.
4. Add now the custom field from the right pane.
5. Save customizations and publish them.
6. Refresh the account form now navigate to the bottom of the form where you added the field in the tab, and expand it.
>> You will see only one option is getting displayed even if the space on the top is more than enough to display it.

Workaround

The workaround for this issue is to place spacers below the attribute/ option set.
Each spacer is equal to one value. E.g. 2 spacers = option set will display two extra values.

Adding spacers on the tab below the option Sets control will create room for displaying the items of the option Sets control.

Note: In this example the bottom fields are not set as visible.

The picture below shows how the form customization and the UI experience is before applying the workaround:

After applying the workaround:

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

This article has the purpose of being an in depth discussion of what is a workflow in CRM, what are possibilities and how you can develop a simple workflow for CRM.

For the purpose of this article, the author decided to go with the CRM 2016 version of the SDK (available here). It is strongly recommended that you keep up to speed with the changes in the SDK, as new information is always released.

The term workflow implies that in order to get to it, there is something that defines it - a business process. A business process can be thought of as set of specific steps that have to be undertaken by a business worker in order to attain a specific objective.

How can we express a business process in CRM? For that we have 4 distinct ways of doing it:

Type of business process	When to use it
Workflow	When you want to automate processes that were accomplished before by one or more people within a business.
Action	When you want to combine a set of steps that are not otherwise made available by standard CRM components
Business Process Flow	When you want to give the users a visual representation of a business processes. Users are guided through the various stages of the process, whether it is a sales or customer service related process
Dialog	When you want the user to interact with the system, and collecting data from users along the steps of the dialog.

Creating a workflow is in Settings -> Processes (It is under Process Center). Once the page loads, you’re greeted with the “My Processes” view, which is the default view for Processes.

Note: The content below can also be found on Technet. Click here to get more information.

Click on the “New” button to create a new workflow. The following dialog appears:

Process Name: You should always put a descriptive enough name for the process, so that once people see the workflow name, have an idea of what it is supposed to do, rather than having to open it to understand what it does.

Category: Since the process we’re trying to create is a workflow, we’ll set this to “Workflow”

Entity: This field defines the primary entity record (in this case, the Account entity), upon which the workflow will perform some action. You can’t change the entity once the workflow has been set.

The “Run this workflow in the background (Recommended)” checkbox is there to let us decide if we want to run the workflow in an asynchronous (i.e. in the background) or in a synchronous fashion. Let’s leave it checked for now.

The last option that we are given is whether we want to create a new process or based on an already existing template. Let’s go with the blank process option.

Once we click OK, the below dialog appears:

We’ll begin with the “Activate As” dropdown. The following values are available:

Option	What happens if I select it?
Process	An actual instance of a workflow will be created every time the workflow is run
Process Template	It will make the workflow available in the template list. This is useful to create a set of workflows that can share a common set of logic.

Under Available to Run you are given three checkboxes:

Option	What does it mean
Run this workflow in the background (recommended)	The workflow will be invoked in an asynchronous fashion once the trigger conditions are met.
As an on-demand process	The user will have the possibility of running the workflow by accessing it in the Run Workflow command under “More Commands” (see screenshot below)
As a child process	This will allow for a workflow to be called from another workflow[HFLVD1] .

The option “Automatically delete completed workflow jobs” will allow for some housekeeping regarding the records left in the AsyncOperationBase table. Do use some caution when deciding not to have completed jobs be deleted (this leads to excessive growth of the AsyncOperationTable – clean-up procedures for this table can be found here)

As you can see, for automatic processes, you have a number of options. Let’s go over each one of them:

The scope restricts the records upon which the workflow will run.

Scope	What records will be affected
User	Records owned by the user that created the workflow
Business Unit	All records within the user’s business unit
Parent: Child Business Unit	All records belonging to the user’s business unit and children business units
Organization	All records[HFLVD2] in the organization.

For the purpose of the exercise, set the scope to organization.

Finally, you get to select when the workflow is started:

Record is created	Upon record creation
Record status changes	When the status of the record changes
Record is assigned	When the record is assigned to a user or team
Record fields change	When a field (from a list of fields selected by the user) changes
Record is deleted	When the record is deleted from the system

Once all these settings are done, we can get to the actual steps of the workflow itself.

From this point onwards, all you need to add to the workflow are its steps. If you click on the Add Step button, you’ll have an array of options, most of which are self-explanatory. It is at this time that we strongly recommend that you have the flowchart of the workflow handy so that you don’t make any mistakes creating the workflow.

Imagine that the existing options you have for a workflow just don’t cut it and you want something that it is just not available within the UI. Here is the point where you need to start looking into code.

And that part happens to be Custom Workflow Activities and Custom XAML Workflows (see doc links here and here).

Be mindful of the following when developing Custom Workflow Activities and Custom XAML Workflows:

For CRM OnPremises

Custom Workflow Activities can run under full trust and partial trust code execution

Custom XAML Workflows can be run.

For CRM Online

Custom Workflow Activities only run under partial trust code execution

Custom XAML workflows are not allowed.

Let us focus solely on the Custom Workflow Activities. Custom XAML Workflows are a whole other topic of discussion and well worth a separate article for themselves.

Let’s then dig deeper into creating Custom Workflow Activities. Below are the prerequisites for developing a custom workflow activity:

Prerequisite	Detail
Which .NET Framework version to target?	.NET 4.5.2
Which DLL’s from the SDK do we need to reference	Microsoft.Xrm.Sdk.dll Microsoft.Xrm.Sdk.Workflow.dll

Now for the code itself:

using System.Activities

using Microsoft.Xrm.Sdk;

using Microsoft.Xrm.Sdk.Workflow

namespace CodeSamples

{

public class MyVeryFirstCodeActivity : CodeActivity

{

protected override Execute(CodeActivityContext context) {}

}

}

Since the underlying workflow technology is Windows Workflow Foundation 4.0, we will require a reference to it (System.Activities)

Every custom code activity will be required to extend the System.Activities.CodeActivity class (hence the inheritance shown above)

Finally, much like the Main function on a C program or the Main method on a C# program, we will need a method where the execution will take place. Since the CodeActivity class is an abstract class and and the method Execute within it is also an abstract method, we will then need to override the Execute method (as per object oriented programming concepts) in order to run the code activity.

Now, is this all there is to it? Unfortunately, that is not the case. Like a plug-in, custom code activities will also require to know what are their input parameters and all of the necessary metadata so that it can then work with CRM information. This documentation link (click here) explains it in greater detail.

Once you’ve set all necessary info, and signed your assembly (remember: All assemblies in CRM need to be strongly signed), it is now time to build it.

Let’s then go to the CRM SDK (note: for this we’re focusing on CRM 2016, so get it from here). Once you’ve opened up the SDK folder, find and execute the Plugin Registration Tool (found in SDK\Tools\PluginRegistration in your CRM SDK installation folder).

Once you’ve registered your workflow assembly by giving it a name and a group name (more details here), it is time that you use it, so go into creating a new workflow, or editing an existing one (assuming you’ve deactivated it first prior to editing) and just click on ”Add Step” and you’ll see your brand new code activity.

That’s it for this in-depth look into workflows and how you can create them both from the UI and within code.

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

The CRM app for Outlook has been introduced in CRM 2015 Update 1 as a preview feature and is fully supported with CRM Online 2016. CRM On Premises Support will come with CRM 2016 Update 1.0.

Microsoft Dynamics CRM App for Outlook is a lightweight app you can use to view Microsoft Dynamics CRM information and track email from within Outlook. The CRM data appears right in your Outlook Inbox.

The CRM App for Outlook is available also in the Outlook Web Access (OWA), the Desktop Outlook (PC or laptop) and as a Mobile App (for Phones and Tablets).

Without requiring installation or configuration, Dynamics CRM App for Outlook allows you to:

Work in the familiar Outlook environment,

Easily track/ untrack emails wherever you are 

Convert an email message into a new CRM Record.

Create CRM contact records for people on the from list that aren’t already included in the CRM database.

Preview information about contacts and leads stored in CRM.

Open CRM records directly to find or enter more detailed information.

Create new CRM records for any entity, as long as the entity has been enabled for mobile ^(*) and for multi-entity search.

^(*) Only entities enabled for mobile are visible in the CRM App for Outlook. To enable an entity for mobile you need to access the specific entity under Settings -> Customization -> Customize the System and mark “enable for mobile”

Support Matrix:

Eligibility Requirements & Deployment:

The CRM App for Outlook can be enabled only for CRM Online 2016 or later deployments. Dynamics CRM App for Outlook availability for Microsoft Dynamics CRM on-premises is planned for CRM 2016 Update 1.0.

Following settings are required in order to be able to enable Dynamics CRM App for a CRM user:

Mailbox Settings

Make sure that the user’s mailbox is configured to synchronize incoming emails through Server side Sync!

User Settings

User needs to have a minimum set of privileges in order to qualify as eligible user for the CRM App for Outlook. The minimum level of permissions is described in the below:

If the above requirements are met, the user should be eligible to use the App.

Users can add the App to their Outlook by accessing Personal Options -> Apps for Dynamics CRM

CRM Administrators have the possibility to push automatically or manually the App for all or some eligible users from Settings -> CRM App for Outlook

NOTE: If you have been using the preview version of the app, you will need to manually remove the app from Outlook and then follow the above listed instructions to get the fully supported app:

For Outlook Desktop -> File -> Manage Add-ins 

For Outlook Web Access -> Settings -> Manage Add-ins

Known Issues:

Error "We’re unable to connect to your Microsoft Dynamics CRM server" when using CRM App for Outlook: https://support.microsoft.com/en-us/kb/3124910

“Your browser is currently unsupported” when accessing the Microsoft Dynamics CRM App for Outlook: https://support.microsoft.com/en-us/kb/3064199

“The language installed on your company’s system isn’t available on the app” when accessing the Microsoft Dynamics CRM App for Outlook: https://support.microsoft.com/en-us/kb/3064234

This operation failed because you're offline” when accessing the Microsoft Dynamics CRM App for Outlook: https://support.microsoft.com/en-us/kb/3064235

“You only have administrative access to Microsoft Dynamics CRM…” when accessing the Microsoft Dynamics CRM App for Outlook: https://support.microsoft.com/en-us/kb/3064256

“This app is not available for your version of Microsoft Dynamics CRM.” when accessing the Microsoft Dynamics CRM App for Outlook: https://support.microsoft.com/en-us/kb/3064263

·Error "Sorry, something went wrong..." when using CRM App for Outlook: https://support.microsoft.com/en-us/kb/3124915

Public Resources:

CRM App for Outlook User's Guide

Deploy CRM App for Outlook

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

Today, when we are authenticating to Office 365, the authentication is "user centred", and not "computer centred" anymore. In this new reality, users who sign in the Office 365 will use different kinds of identities: Microsoft Account (Xbox, Skype, One Drive…) or Organizational account (for O365, Intune or CRM online).

A Microsoft Account, formerly known as Windows Live ID, is the combination of an email address and a password used to sign in to services like Xbox, outlook.com, skype, OneDrive…

Regarding the Organizational account, Office 365 has two systems that can be used for user identities:

• Work or school account (cloud identity)   Users receive Azure Active Directory cloud credentials—separate from other desktop or corporate credentials—for signing into Office 365 and other Microsoft cloud services. This is the default identity, and is recommended in order to minimize deployment complexity. Passwords for work or school accounts use the Azure Active Directory password policy.

• Federated account (federated identity)   For all subscriptions in organizations with on-premises Active Directory that use single sign-on (SSO), users can sign into Office 365 services by using their Active Directory credentials. The corporate Active Directory stores and controls the password policy.

For information about User Account Management, please check the following article:

User Account Management

https://technet.microsoft.com/en-us/library/office-365-user-account-management.aspx

Note: As this article has the purpose to introduce the Identity and Authentication in the cloud using Office 365, we will focus on the Organizational accounts from now.

Office 365 uses the cloud-based user authentication service Azure Active Directory (AAD) to manage users. You can choose from three main identity models in Office 365 when you set up and manage user accounts:

a) Cloud identity.

All is done in the cloud and you manage your user accounts in Office 365 only. No on-premises servers are required to manage users.

b) Synchronized identity.

Synchronize on-premises directory objects with Office 365 and manage your users on-premises. You can also synchronize passwords so that the users have the same password on-premises and in the cloud, but they will have to sign in again to use Office 365.

c) Federated identity.

Synchronize on-premises directory objects with Office 365 and manage your users on-premises. The users have the same password on-premises and in the cloud, and they do not have to sign in again to use Office 365. This is often referred to as single sign-on.

For more information about this topic, please check the following article:

Understanding Office 365 identity and Azure Active Directory

https://support.office.com/en-us/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9

When you are using CRM Online and Office 365, it is important understand which identity model is used to have a better understanding about how your users are accessing O365. On top of it , you can also consider several factors as time, complexity, and cost, which will vary from one organization to another.

You can check the user identity used in O365 accessing "User and groups", selecting

"Active Users", and checking the "Status" as described below:

More references:

What is my user ID and why do I need it for Office 365 for business

https://support.office.com/en-us/article/What-is-my-user-ID-and-why-do-I-need-it-for-Office-365-for-business-37da662b-5da6-4b56-a091-2731b2ecc8b4

Office 365 Core Identity Scenarios

https://blogs.technet.microsoft.com/uspartner_ts2team/2013/09/11/office-365-core-identity-scenarios/

Identity and Authentication in the cloud: Office 2013 and Office 365 (Poster)

https://www.microsoft.com/en-us/download/confirmation.aspx?id=38193

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport

This article could be of interest to you if you use email attachments on a large scale in CRM with images such as signatures in emails.

If you look into your database storage report and see that Email attachments is a high usage in the db size, this may be of interest to you.

In CRM, email attachments can be removed only if email is in draft state. You can create a workflow to change the status of the emails  and then delete the attachments manually; but it is not practical to manually delete the attachments from hundreds of emails.

There was a workflow solution on codeplex which was used to bulk delete the attachments using a custom workflow. 

This solution does not function in the latest version of CRM though.

Our engineer Subodh has created an updated version of that workflow so would work in CRM 2016.

This is the source code of the solution:

using Microsoft.Crm.Sdk;

using Microsoft.Xrm.Sdk;

using Microsoft.Xrm.Sdk.Workflow;

using System;

using System.Activities;

using System.Collections.Generic;

using System.Linq;

using Microsoft.Xrm.Sdk.Query;

using System.Text;

namespace GWF

{

public class WorkFlow : CodeActivity

{

    [RequiredArgument]

    [Input("Email")]

    [ReferenceTarget("email")]

    public InArgument<EntityReference> rEmail { get; set;}

    protected override void Execute(CodeActivityContext executionContext)

    {

        try

        {

            ITracingService trace = executionContext.GetExtension<ITracingService>();

            IWorkflowContext context = executionContext.GetExtension<IWorkflowContext>();

            IOrganizationServiceFactory IOSF = executionContext.GetExtension<IOrganizationServiceFactory>();

            IOrganizationService IOS = IOSF.CreateOrganizationService(context.UserId);

            if (IOS != null)

            {

                trace.Trace("Organization Service Created");

            }

            EntityReference rem = rEmail.Get(executionContext);

            Entity REmail = IOS.Retrieve(rem.LogicalName, rem.Id, new ColumnSet("attachmentcount"));

            int atc = (int)REmail["attachmentcount"];

            try

            {

                if (atc > 0)

                {

                    QueryExpression queryAtt = new QueryExpression("activitymimeattachment");

                    queryAtt.ColumnSet = new ColumnSet(new string[] { "activityid", "attachmentid" });

                    queryAtt.Criteria = new FilterExpression();

                    queryAtt.Criteria.FilterOperator = LogicalOperator.And;

                    queryAtt.Criteria.AddCondition(new ConditionExpression("activityid", ConditionOperator.Equal, REmail.Id));

                    EntityCollection eatt = IOS.RetrieveMultiple(queryAtt);

                    for (int i = 0; i < atc; i++)

                    {

                        IOS.Delete(eatt[i].LogicalName, eatt[i].Id);

                    }

                }

}

            catch (Exception e) { throw new InvalidPluginExecutionException("Error occurred : ", e); }

        }

        catch (Exception ex)

        {

            new InvalidPluginExecutionException(String.Format("An error occurred in {0} plugin " + ex, this.GetType().ToString()));

        }

    }   

}

}

You can create the solution using this code and steps:

Build the Code.

Deploy it using PRT in any test CRM.

Create the solution in test CRM and add the workflow created by the plugin into that solution.

Export the solution as a managed solution.

Once the solution is imported into your CRM, these are the steps to bulk delete the attachments from emails:

Import the solution.

Advance find the emails with largest attachments

Select them and run the on-demand workflow which will be available after importing the solution.

You do not need to change the status of the email.

You can download the DeleteAttachmentsFomEmails_8_0_0_managed from here if you would like to test it.

Best Regards

EMEA Dynamics CRM Support Team

Share this Blog Article on Twitter

Tweet

Follow Us on Twitter

Follow @MSDynCRMSupport