We've got a workflow which creates 3 entities:
SourceAssessment
SourceLegal
SourcePartnershipValidation
each entity have got 1 lookup field under Business Process Flow:
And the same workflow is configured to update the above 3 lookup fields with newly created entities:
However, the creation part seems to be working fine but not the assigning part.
Have tried implementing the Automatic Record Creation and Update Rules from Service Management & Business Management Settings
How to fix it?
You wanted to assign the 'Source Legal' record value to the Project record. For that, You have to map the created records from 'Local Values' group in 'Look for' dropdown from 'Set Properties' window.
See the slug (yellow placeholder text) for difference. This will work.
Related
I'm using the Dynamics connector in Azure Data Factory.
TLDR
Does this connector support loading child records which need a parent record key passed in? For example if I want to create a contact and attach it to a parent account, I upsert a record with a null contactid, a valid parentcustomerid GUID and set parentcustomeridtype to 1 (or 2) but I get an error.
Long Story
I'm successfully connecting to Dynamics 365 and extracting data (for example, the lead table) into a SQL Server table
To test that I can transfer data the other way, I am simply loading the data back from the lead table into the lead entity in Dynamics.
I'm getting this error:
Failure happened on 'Sink' side. ErrorCode=DynamicsMissingTargetForMultiTargetLookupField,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=,Source=,''Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Cannot find the target column for multi-target lookup field: 'ownerid'.
As a test I removed ownerid from the list of source columns it loads OK.
This is obviously a foreign key value.
It raises two questions for me:
Specifically with regards to the error message: If I knew which lookup it needed to use, how can I specify which lookup table it should validate against? There's no settings in the ADF connector to allow me to do this.
This is obviously a foreign key value. If I only had the name (or business key) for this row, how can I easily lookup the foreign key value?
How is this normally done through other API's, i.e. the web API?
Is there an XRMToolbox addin that would help clarify?
I've also read some posts that imply that you can send pre-connected data in an XML document so perhaps that would help also.
EDIT 1
I realised that the lead.ownertypeid field in my source dataset is NULL (that's what was exported). It's also NULL if I browse it in various Xrmtoolbox tools. I tried hard coding it to systemuser (which is what it actually is in the owner table against the actual owner record) but I still get the same error.
I also notice there's a record with the same PK value in systemuser table
So the same record is in two tables, but how do I tell the dynamics connector which one to use? and why does it even care?
EDIT 2
I was getting a similar message for msauto_testdrive for customerid.
I excluded all records with customerid=null, and got the same error.
EDIT 2
This link appears to indicate that I need to set customeridtype to 1 (Account) or 2 (Contact). I did so, but still got the same error.
Also I believe I have the same issue as this guy.
Maybe the ADF connector suffers from the same problem.
At the time of writing, #Arun Vinoth was 100% correct. However shortly afterwards there was a documentation update (in response to a GitHub I raised) that explained how to do it.
I'll document how I did it here.
To populate a contact with against a parent account, you need the parent accounts GUID. Then you prepare a dataset like this:
SELECT
-- a NULL contactid means this is a new record
CAST(NULL as uniqueidentifier) as contactid,
-- the GUID of the parent account
CAST('A7070AE2-D7A6-EA11-A812-000D3A79983B' as uniqueidentifier) parentcustomerid,
-- customer id is an account
'account' [parentcustomerid#EntityReference],
'Joe' as firstname,
'Bloggs' lastname,
Now you can apply the normal automapping approach in ADF.
Now you can select from this dataset and load into contact. You can apply the usual automapping approach, this is: create datasets without schemas. Perform a copy activity without mapping columns
This is the ADF limitation with respect to CDS polymorphic lookups like Customer and Owner. Upvote this ADF idea
Workaround is to use two temporary source lookup fields (owner team and user in case of owner, account and contact in case of customer) and with parallel branch in a MS Flow to solve this issue. Read more, also you can download the Flow sample to use.
First, create two temporary lookup fields on the entity that you wish to import Customer lookup data into it, to both the Account and Contact entities respectively
Within your ADF pipeline flow, you will then need to map the GUID values for your Account and Contact fields to the respective lookup fields created above. The simplest way of doing this is to have two separate columns within your source dataset – one containing Account GUID’s to map and the other, Contact.
Then, finally, you can put together a Microsoft Flow that then performs the appropriate mapping from the temporary fields to the Customer lookup field. First, define the trigger point for when your affected Entity record is created (in this case, Contact) and add on some parallel branches to check for values in either of these two temporary lookup fields
Then, if either of these conditions is hit, set up an Update record task to perform a single field update, as indicated below if the ADF Account Lookup field has data within it
I'm basically trying to create a primary ID between CRM and QuickBooks. Figured I'd just use the existing PK in CRM for the lookup. I'd like the PK to visible to the user, but not editable in CRM.
This has presented several problems in that you can't do that out of the box. I thought I read somewhere you could either via business rule or calculated field, but I haven't had luck with that.
It sounds like it would require web resources if I were to go this route.
The other option would be to just generate unique values for every record in Accounts and Contacts.
Does this automatically populate existing records or just new records? How do I get it to populate existing records?
You can use Auto number manager for configuring an auto-number attribute in every entity. This seeds a number based on configured format for new records. Uniqueness assured by SQL sequence feature & no need of any extra plugin/workflow.
For existing records - you can design a workflow along with a temp entity to assign auto-number. Read more.
Otherwise you can use SSIS + Kingswaysoft package to generate auto-number & assign for existing records.
I am suggesting you to create a new text field on the entity and create a pre plugin that will get the record primary GUID id from context and will set this GUID into the newly added attribute. You can set this field as read-only of form as well.
OR you can generate new GUID as well into the plugin.
I'm working a custom workflow activity and would like to allow the user to select one of the entities available from within the workflow. This would be like selecting the entity in an update status activity. The list would include the primary entity, all of its associated parent entities, and any entities created within the workflow (e.g. if I created a task with the create activity, that task would be in the list).
Is there some way to do this?
Thanks!
Workflow has major shortcomings when it comes to things like this. You can add metadata to dependencies ( [CrmInput] and [CrmReferenceTarget("account")] ), but you'll need a property per entity you intend to support. I don't know if you could include multiple CrmReferenceTarget tags per property.
So even if you go through setting up a workflow activity with every lookup (which will require a code change for every new entity), you still have to take the care to set the right lookup in your code - and choose from ALL (not filtered based on your entity). Which is clearly not what you want.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.
I have a custom entity in Microsoft CRM (4.0). The user has to input records however usually they have a batch of 20+ records that are almost the same apart from 2 or 3 fields which need changing. I know I need to write some custom code to enable this functionally. However can anyone recommend any methods to do this.
Ideally there should be a button that will save and create a copy as a new entity.
My Current way of thinking is to pass all the details as part of the URL and use javascript to strip them out on the page load event. Any ideas welcome.
Thanks
Luke
I found the answer here:
http://mscrm4ever.blogspot.com/2008/06/cloning-entity-using-javascript.html
I've used it and it appears to work well.
Since there are numerous fields, but only certain fields values are different, then i am thinking to set the default value to all the fields, so that users just need to alter those values when needed.
In my approach, i will hook a javascript function on load of the form data entry screen and use XmlHttp approach/Ajax approach to hook to the custom web service to pull/retrieve the default values of each fields. Or you can set those values at the javascript function itself, but the drawback of this, it's difficult to customize later. So i will choose the approach to hook to the custom web service and retrieve those value from some application parameter entity.
Your idea of providing a "clone" button is also a great idea, which means that it will duplicate all the attributes of the previous record, into a new record, so that it will save time for data entry person to customize the different value
EDIT
Since you would enter records in batch mode, how about customizing .ASPX screen to enter records. By customizing through .ASPX screen, you can use a tab , so that users can browse through tabs, to customize the value/attribute of each record.
There will be a "save" button as well as "clone" button to clone some common attribute or value.
I would create a custom web service that would accept the entity type and the ID of the record I'm cloning. Your "Save and Clone" button would call the service, and the service would handle the details of retrieving the current record and deciding which fields to set on the new record. The service creates the record, and sends the Guid of the record back to your button, which then opens up the newly created record.
This way, you avoid the messiness of setting/getting values in JavaScript and tying which fields to set/retrieve directly to your OnLoads, as well as avoiding the possibility of query string that's too long.
The service could easily be sufficiently generalized so that all you'd have to do is add your button to any entity, and it would work, assuming you'd set up your service to handle that particular entity.
One possible downside is that since the clone record button would actually create the record, the user would be forced to delete the cloned record if they decided they didn't want to clone the record after all.