The CDS (current environment) connector is the newer version of the two CDS connectors that are available. It has nice new features such as a Create/Update/Delete trigger, support for Service Principals in solution aware Flows and some smaller features in its different actions. It’s the go-to connector to use in solution aware Flows.
Despite all the improvements, the connector has also taken a step backward when it comes to referencing records. With the original CDS connector, referencing records is as simple as using dynamic content and pointing to a record. In the example illustrated below, all that needs to be done is to choose a project’s id/GUID from a previous action (or in this case the trigger) by using dynamic content. This relates the project task in the Create a new record action to the project that caused the Flow to fire off.
With the new CDS (current environment) connector, the results from the previous example will be different. The Flow will fail with an error “Resource not found for the segment xyz”. This happens because the new CDS (current environment) connector expects the referenced attribute values in the form of OData id:
Typing in an entity name is naturally one approach to solving the problem. Personally I’m not a huge fan of typing in values to actions. It’s also a bit of work to dig out the exact name for an entity, as the naming convention differs between core CE, Field Service and Project Service Automation. While core CE doesn’t have a prefix, Field Service and PSA use msdyn_. Then again Universal Resource Scheduling doesn’t use a prefix, so as you can by now guess, the differences in entity naming conventions in Dynamics 365 for Customer Engagement make it challenging to remember entity names.
To make life simpler, an action including an entity’s name is needed. One way of getting to a name is by using the Get record action. An id/GUID from a trigger’s output can be used as dynamic content in the Get record action. The output of that action will then include the entity name in plural and the id/GUID of the related record.
To extract the string value from @odata.editLink, an expression is needed. I have used a compose action for the expression and then use the output of the compose in the following action that creates a project task. The expression itself isn’t really “citizen developer” friendly but it does get the job done. If you copy this somewhere for future reference, the only thing that you need to change in the expression is the name of the Get record action. To get the entity name and id/GUID, a first+split+last+split is used:
I’ve made a short video about this as well. I hope this small trick helps you reference records more easily! Kudos to MVP Sara Lagerquist for helping me out!