I have one similar, I use an "Update" block with:
- AlternateContactLink_Category = "Employee"
- ProfileLink_Category = "Employee"
- AlternateContactLink = $(ProfileLink_RecID)
- Contact Link = $([^Employee# where LoginId == [this]LoginId]RecId)
- The first two (The "Employee" ones) I am pretty sure are not mandatory... but it works well like that, so I am not going to do more testing...
- The last one is using the following format: [^BusinessObjectName# where FieldValue == value]FieldName
- BusinessObjectName should be "Employee" unless you made changes to the OOB design.
- FieldValue is a field on the BusinessObjectName (Employee in our case) which you are going to use for comparison.
- value is going to be compared against FieldValue, if they are the same, the system will return the FieldName (in our case it HAS to be RecId) from BusinessObjectName.
- value can be a fixed value, or it can be a reference on your current object (In our case the main Service Request).
- To avoid issues, I would use one "Update" block to store the unique information of your user in the Service Request (LoginId, Email...) and then a second "Update" block with the actual linking.
Any question, you know where to find me!
this works fine. Many thanks. I'm now stuck on the syntax to add the field AA_UID of the object Frs_CompositeContract_Contact to a task.
I cannot find a manual that explains this syntax.
On the task creation object, I have tested many syntaxes such as : $([Frs_CompositeContract_Contact#.ServiceReqAssociatedReportedBy]AA_UID)
Can you enlighten me again ?
1 of 1 people found this helpful
Personally, for those kind of situations the easiest way I see to do it would be by storing the information on the Service Request and refer to the Service Request when grabbing for the task... Let me explain myself (Note that I am theorizing because I don't have that field on my CompositeContract and I use the Employee object mostly instead of the Composite):
- Create a field on the Service Request called something like AA_UID (Can be anything as long as you know it)
- At linking push the AA_UID field from the "Frs_CompositeContract_Contact" object to the AA_UID of the "Service Request" object (See the example, the field CustomerPhone of my Service Request is getting populated with the information contained in the field Phone1 of my "Frs_CompositeContract_ContactEntity" object):
- Create a field called AA_UIDin your "Task#Assignment" object (Again, the name is up to you).
- At linking push the AA_UID field from the "Service Request" object to the AA_UID of the "Task#Assignment" object (See the example, the field ParentObjectDisplayID of my Task is getting populated with the information contained in the field ServiceReqNumber of my "Service REquest" object):
The other option would be to do an absolute reference like before; you would put an "Initialization rule" for the AA_UID filed on the Task with the following Expression:
$([^Frs_CompositeContract_Contact# where UniqueIdentifier == [this]UniqueIdentifierOnTask]AA_UID)
- UniqueIdentifier would be a unique field (a filed that won't give in any case 2 or more results if you look for it), as you are looking for Contacts I would say the email (if you are enforcing to always add an email) can be a choice, but anything that you can know upfront (that's why I do not recommend RecId) and that can only have one occurrence.
- UniqueIdentifierOnTask would be a field on the Task that stores the same unique field that you can find on the Contract.
Let me know if any of those works for you!
thanks for the elaborate explanation.