We can't extract data from the incoming Salesforce Object in the Journey Builder to the Custom Activity we made. We have already followed the syntax that was instructed in your documentation -> https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-apis.meta/mc-apis/how-data-binding-works.htm (under Event Context section).
We are primarily using Postmonger for our Custom Activity, and in our config.json under the inArguments, we input something like below to fetch the data from the Salesforce Object:
"fieldKey": "{{Event." + [ eventDefinitionKey ] + ".Task:Field_Name__c}}"
The eventDefinitionKey we get from the data loaded by triggering the requestedTriggerEventDefinition exposed by the Postmonger.
The resulting inArguments from above would be something like this:
"fieldKey": "{{Event.SalesforceObjacf28b016bf83c75b4926e0ec292eda5.Task:SMS_Content__c}}"
And based from the documentation mentioned previously, that syntax should be enough, yet we cannot retrieve it on our Custom Activity.
Another thing to note is that we can fetch information using the same syntax if the entry object is a Data Extension like below:
"fieldKey": "Event.DEAudience-e56d43c3-e2cf-60f1-fecd-ecf4d358d7b4.Field_Name"
The syntax above work which uses Data Extension is okay, but the one with the Salesforce Object does not.
What are we doing incorrectly here or is not possible entirely?
NOTE: the journey gets triggered by creating a task in Service Cloud
We put " around the eventDefinitionKey and the field name as well, and it works from Salesforce Data sources.
Something like:
"fieldKey": '{{Event."SalesforceObjacf28b016bf83c75b4926e0ec292eda5"."Task:SMS_Content__c"}}'
Note the switch to single quotes and how we're explicitly wrapping those inner attributes with double quotes
Update Oct 2020
Please see this post here which allows you to see the full merge fields of the entire Data Extension (no matter what type it is)
Related
I'm managing a company website, where we have to display our products. We however do not want to handle the admin edit for this CPT, nor offer the ability to access to the form. But we have to read some product data form the admin edit page. All has to be created or updated via our CRM platform automatically.
For this matter, I already setup a CPT (wprc_pr) and registered 6 custom hierarchical terms: 1 generic for the types (wprc_pr_type) and 5 targeting each types available: wprc_pr_rb, wprc_pr_sp, wprc_pr_pe, wprc_pr_ce and wprc_pr_pr. All those taxonomies are required for filtering purposes (was the old way of working, maybe not the best, opened to suggestions here). We happen to come out with archive pages links looking like site.tld/generic/specific-parent/specific-child/ which is what is desired here.
I have a internal tool, nodeJS based, to batch create products from our CRM. The job is simple: get all products not yet pushed to the website, format a new post, push it to the WP REST API, wait for response, updated CRM data in consequence, and proceed to next product. Handle about 1600 products today on trialn each gone fine
The issue for now is that in order for me to put the correct terms to the new post, I have to compute for each product the generic type and specific type children.
I handled that by creating 6 files, one for each taxonomy. Each file is basically a giant JS object with the id from the CRM as a key, and the term id as a value. My script handles the category assertion like that:
wp_taxonomy = [jsTaxonomyMapper[crm_id1][crm_id2]] // or [] if not found
I have to say it is working pretty well, and that I could stop here. But I will have to take that computing to the wp_after_insert_post hook, in order to reaffect the post to the desired category on updated if something changed on the CRM.
Not quite difficult, but if I happen to add category on the CRM, I'll have to manually edit my mappers to add the new terms, and believe me that's a hassle.
Not waiting for a full solution here, but a way to work the thing. Maybe a way to computed those mappers and store their values in the options table maybe, or have a mapper class, I don't know at all.
Additional information:
Data from the CRM comes as integers (ids corresponding to a label) and the mappers today consist of 6 arrays (nested or not), about 600 total entries.
If you have something for me, or even suggestions to simplify the process, I'll go with it.
Thanks.
EDIT :
Went with another approach, see comment below.
I've followed the Azure Indoor Maps Creator tutorial here but used a python script from another repository here to make it simpler to upload the map files. No PostMan required basically.
The sample wires up a levelchanged event handler and outputs the event data to console. The event's data for facilityId is always FCL13. I cannot find where this data is specified anywhere. Not in the python script, the sample data zipfile manifest.json, nor in the DWG files (with my limited ability to view those).
I assume I should be able to specify which facility I am uploading data for so would either expect the API calls to be provided this (from the python script), or it should be some metadata within the DWG files.
My intention was to upload more than one building's floor maps so need the facilityId to be configurable. Having specific tilesets associated to different facilityIds allows me to know which facility had its level changed during a levelchanged event.
Where is the facilityId data specified for a specific map data upload?
All Ids (facilityId, levelId, unitId, etc.) are generated when you create a dataset. These Ids are not meant to be set manually.
It is possible to list facilityIds loaded in the map, along with their names, address info, etc. that was provided in manifest.json.
Note: It looks like the 'indoorTiles' source lacks the getShapes() method so a workaround is required to query the underlying mapbox.
map._getMap().querySourceFeatures('indoorTiles', {sourceLayer: 'Indoor facility'});
From Mapbox's documentation on querySourceFeatures():
Because features come from tiled vector data or GeoJSON data that is converted to tiles internally, feature geometries may be split or duplicated across tile boundaries and, as a result, features may appear multiple times in query results.
So, I've been attempting to gather picklist dependencies per Opportunity record type for my lightning components. I have been able to retrieve Standard Field dependencies by RecordType, but it the Tooling API will not return the custom field dependencies. Standard calls and queries will not work either, as they state that the field has no controlling value or dependency.
Given this information I suspected that there was a table that is hidden somewhere that contains the keys for the RecordType and FieldDefinition, hopefully with a nested Metadata object.
I found an Id in one of the parameters in the setup menu for a Record Type and Id.getSObjectType() on it. The table name is CustomFieldDefinition. However, it is not accessible via SOQL or the Tooling API.
Has anyone accessed this table? Or has anyone been able to retrieve the field-record type picklist dependencies on custom fields AND standard fields?Tooling API ResponseDebug Log with SObject Name
I think you're doing it wrong.
"Controlling field" would be another picklist or a checkbox for example, something you change during same edit action. If you have dependency to record type - in that sense it's not a controlling field. Sure, you change record type and picklist changes - but really everything would change, it should be a different page layout (different fields shown, marked readonly/required etc). There's a reason that record type change is not done on normal edit screen, you do it by clicking special link on detail view and then everything "explodes".
Have a look at "User Interface API" - set of tools meant to help your custom app (mobile? desktop?) steal recreate a normal page layout. This one might be especially useful: https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_resources_picklist_values_collection.htm
There's even a Trailhead: https://trailhead.salesforce.com/en/content/learn/modules/user-interface-api (skim through whole set but especially read last module)
And since you mentioned Lightning Components - are you aware of these ready tools:
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.reference_ui_api
getPicklistValuesByRecordType
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.reference_generate_record_input_create
or maybe you don't have to code it all and stuff like <lightning-record-edit-form> with recordtypeid passed to it will solve all your problems
Have a look, if I didn't give you a working solution then at least you have some keywords to Google around. If you're still stuck - try to post a code sample as new question?
I am looking to create a feature whereby a User can download any available documents related to the item from a tab on the PDP.
So far I have created a custom record called Documentation (customrecord_documentation) containing the following fields:
Related item : custrecord_documentation_related_item
Type : custrecord_documentation_type
Document : custrecord_documentation_document
Description : custrecord_documentation_description
Related Item ID : custrecord_documentation_related_item_id
The functionality works fine on the backend of NetSuite where I can assign documents to an Inventory item. The stumbling block is trying to fetch the data to the front end of the SCA webstore.
Any help on the above would be much appreciated.
I've come at this a number of ways.
One way is to create a Suitelet that returns JSON of the document names and urls. The urls can be the real Netsuite urls or they can be the urls of your suitelet where you set up the suitelet to return the doc when accessed with action=doc&id=_docid_ query params.
Add a target <div id="relatedDocs"></div> to the item_details.tpl
In your ItemDetailsView's init_Plugins add
$.getJSON('app/site/hosting/scriptlet.nl...?action=availabledoc').
then(function(data){
var asHtml = format(data); //however you like
$("#relatedDocs").html(asHtml);
});
You can also go the whole module route. If you created a third party module DocsView then you would add DocsView as a child view to ItemDetailsView.
That's a little more involved so try the option above first to see if it fits your needs. The nice thing is you can just about ignore Backbone with this approach. You can make this a little more portable by using a service.ss instead of the suitelet. You can create your own ssp app for the function so you don't have to deal with SCAs url structure.
It's been a while, but you should be able to access the JSON data from within the related Backbone View class. From there, within the return context, output the value you're wanting to the PDP. Hopefully you're extending the original class and not overwriting / altering the core code :P.
The model associated with the PDP should hold all the JSON data you're looking for. Model.get('...') sort of syntax.
I'd recommend against Suitelets for this, as that's extra execution time, and is a bit slower.
I'm sure you know, but you need to set the documents to be available as public as well.
Hope this helps, thanks.
I'm trying to get over a limitation in Salesforce where Lead objects can't have related lists that convert with the Lead over to Opportunity, Contact and Account. I have set up 4 objects of type Lookup Relationship, and created a dummy record in each.
I want to use Custom Settings to store the id of each of these dummy records, so that when the Lead converts, any custom objects can also convert to objects with Master/Detail relationships on the respective standard objects.
My trigger on Lead(after update) tries to create a Map of the Custom Settings:
Map cs = AcctId__c.getAll();
AcctId__c is the Custom Setting api name. Compile time is giving me the above message.
Now, I copied this code directly from the Salesforce documentation. What am I forgetting?
I believe that you must include the actual map definition <String,AcctId__c> after the word Map.
Check out this page.
http://www.salesforce.com/us/developer/docs/apexcode/Content/langCon_apex_collections_maps.htm