I’ve been having a hell of a time with this one for the past few days. I’m developing a project that validates and, if necessary, installs, repairs, or updates any external values needed. This includes SQL data and Application Properties in the ProcessManager portal/DB. The SQL part was no issue, but the profile values were making me really work hard for success.
Set Profile Values is the component I finally got to work.
The problem is how a profile database table is created by the ProcessManager portal. This is what a freshly created table looks like:
So let’s note that the profile is created with both a null reference type id and reference name.
Now, let’s have a look at the Set Profile Values component as it’s created on the Workflow canvas.
Well, we’re unable to match the nulls, as the fields are required, and null isn’t allowed. When this component is configured to its own satisfaction, like so:
and the Guid is just a random id, a second entry is created in the table.
Now if we want to actually update the original ProcessManager-spawned profile definition values, we’ll have to match both the _reference_type_id as well as the _reference_id.
The next steps can vary, but in my case, I just gave the original line an update and deleted the new line.
update profile_test_profile2 set _reference_type_id = 'Application Properties' ,_reference_id = '53CABABF-C5D2-4D12-BC45-D35FE2570737' where profile_test_profile2_id = '8e9f49a9-abba-42a0-b355-87d0f8f528c7' --check this guid
After that, I ran the project again. Here were the results.

So after way too many hours spent on the plethora of ambiguously-named “profile” components trying to figure this out, I can finally move on.