I'm having a problem when copying customization between organizations with solution export/import.
That's every time that I copy data between different organizations/environments, I have to go through all workflows and change the references to CRM data, i.e 'From' field of an e-mail, that can be a queue or user mail.
In the new solution I have "Service" and it should be Service, so having the same name isn't a solution, so I think this is regarding to the GUID of the elements, but there is any option while exporting, I suppose, for avoid that, any freeware tool for that? Thanks!
This solution requires some .Net development, but once it is set up is pretty extensible. Either create a Configuration entity that only ever has one record or create an xml web resource that that stores all the environment variables like references to users, server settings url, etc.
To access your config entity (or web resource) from a Workflow you can create a simple workflow activity that just returns the first record of the configuration entity. Once you have it you can reference any property on it and since the data in that configuration is a record it unique to that environment.
Like I mentioned you can probably use an XML resource to do it, but retrieving an entity is easier, and you get the CRM UI for option sets and lookups and you can restrict who can edit it with security. You can also add new fields at any time and not ever have to change your WF activity code.
Related
I'm completely new to Sharepoint so keep that in mind when answering or assuming things.
Anyways, we have a CRM 2015 Online Update 1 and Sharepoint Online and those are integrated (not by me). Now when an end-user goes to Account -> Documents the CRM will automatically ask if the user wants to create a folder to Sharepoint. That's fine, but naming convention seems to be "AccountName_AccountGuid". We would like to change that to "AccountName_OurOwnID" where OurOwnID is a custom field in CRM that is unique for every account.
So my question is how would one do this?
EDIT: All I can think of now is to create a plugin that'll be launched when ever a sharepointdocumentlocation entity is created and basically create a new folder with wanted name and then delete the original folder in Sharepoint and then connect the new folder with sharepointdocumentlocation.
Sub-question: Is there a way to tell CRM to stop asking if the user wants to create a new folder? In my case it's unwanted feature but since it is there at least we should make sure that names of the folders will be ok.
The folder name with the guid is default behavior which cannot be altered.
If you want to develop a plugin, look at this post: https://crmconsultancy.wordpress.com/2011/10/27/crm-2011-integration-with-sharepoint-custom-document-management/
Keep in mind, if you want to create objects in SharePoint from CRM online you have two options:
Add the SharePoint.Client assembly with ILMerge. Officialy this is not supported.
Or use the rest endpoint of SharePoint. This is an interesting post to read: https://bingsoft.wordpress.com/2013/06/19/crm-online-to-sharepoint-online-integration-using-rest-and-adfs/
I am coming into an existing SCCD project and there is a custom field that is maintained between the Service Request and Incident forms. The problem is that the field is not being carried over properly. I suspect this is an issue within the workflow? Is there a proper way to debug or search for this problem area? So far, I've been poking around the 500+ workflow items for each the Service Request and Incident objects.
We ran into a similar situation where a custom field in the work order table was transfer over when we duplicated the work order. In that case, we had to look for the domain responsible for passing specific fields to be included in the duplication. It was a matter of adding the new custom field (dept) to the domain entry.
Other times, you may have to create an automation script, or modify the Java .class file (decode, rewrite, and recompile).
In my solution I have a workflow where one step contains a reference to Queue. After importing this solution on another CRM instance this workflow could not be activated because it contains an invalid reference - Queue can not be resolved. Queue with same name is created on new CRM but resolving is probably based on record Guid.
Now, I'm wondering, is there a way to edit workflow steps using CRM SDK? Whole process of CRM solution deployment is automated. And I want to remove all manual work. Some example would be great :)
Thanx in advance!
There are 2 things you can do if you are having issues with the Guids not matching in a workflow lookup when deploying from one environment to another.
Use the API to create those records referenced in the WF. When you create a record you can actually specify the Guid that it uses as the id. So write a tool or see if one exists already that will create some default data for your environment.
Use a configuration entity with references to all the EntityRefrences needed in your WFs. Then you can create a custom workflow activity to retrieve the configuration entity record (there should only ever really be one) that contains all the references in that environment.
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
we are currently working on a specific CRM development. As part of this development we are working with a different supplier who have provided us with a 'core' managed solution, a toolkit of sorts. This toolkit contains a number of entities/web resources etc but crucially contains the case and contact (renamed to customer) entities. As part of our development we need to extend these entities by adding attributes/amending form layout etc for both these entities.
should i create a new unmanaged solution - select add existing - choose the customer entity.
I can then make my changes (new attributes, form layout changes etc)
I then publish my unmanaged solution as a managed solution to import into a UAT/Prod environment.
Would this approach work ok?
What if the supplier make changes to their core entity and provide us with an updated release? what happens then or what should i do?
There are a couple of attributes (title and ethnicity) that are part of their entity but i need to work of global option sets so i have create 2 new attributes and these are displayed on the form in place of their's. I have not removed theirs but could this cause issues?
any help appreciated
chris
You are right on in the first paragraph, you would need to create a new solution and amend their entities. When you import their changes it will add on any additions to those entities. Importing customizations should never remove anything, you have to do that manually. Although unlikely, it is possible that the vendor may release a new version that requires you to roll back your customizations and reinstall it. In this instance you would need to come up with an upgrade plan and take into account all of the dependencies of the system.
I would imagine that those attributes would be dependencies of their managed solution and suspect that CRM won't let you delete them. If you are able to delete the fields and recreate them using global option sets there should be no issues so long as you use the same picklist integer values and schema names for the fields. Microsoft CRM basically copies all of the global option set values to the entity that you put them on so externally there is no difference between the standard and global option sets. Obviously a future upgrade by the vendor may force you to delete it all and recreate everything again manually (or via code using the CRM web services), but that is something you would have to take into account.
What the disadvantage here is, is if you create an entity, attribute or relationship in Dev and deploy to forward facing entity, if you then remove that entity, attribute or relationship in Dev, you must "uninstall" that solution. Of course, if you have critical data in that forward facing environment, it is gone when that solution is removed. So, if you deploy from Dev to forward facing, if in the future you no longer need that entity, attribute or relationship, although you can remove it from forms, it will always remain an artifact in your system. This is a disadvantage when working with Managed solutions.