To copy the Owner field into a text field should be an easy task, but what if the Owner field can be different objects (polymorphic)? Luckily the system will automatically generate one field for each object, and we check for the null values to see what object is the current owner. This post will also discuss how to choose between Process Builder or Flow for this use case, so let’s dive in!
Lulu Mobile uses the standard Case object. Whenever the users reassign the cases, they want to track the current and prior owners’ names into two text fields. They don’t need to populate the current user field when a case is created. However, they do want to keep these two text fields editable by the users.
We will use a Record-Triggered Flow with the Before trigger to achieve this since we are updating the same record.
The system will auto-generate two fields – Owner (Group/Queue) and Owner (User). If the owner is a queue, the Owner (Group/Queue) Id will have the queue Id and the Owner (User) Id will stay null. If the owner is a user then vice versa. Thus, we can utilize this feature to find out whether the owner is a group or queue.
Alternatively, you can also use Owner Id and check the prefix, but the first solution will be more easily readable.
There are several considerations to the presented solution:
1. It can be simplified if the text fields don’t need to be editable
If you only need to copy the value, you can consider using a formula text field instead. However, you can’t get the prior owner name in a regular formula field, so you still need part of this solution to copy the prior owner value. To achieve this, simply reduce the Decision outcomes to 2 – Prior Owner is User or Prior Owner is Group.
2. It only works on record update, not create,
The reason is that IsNew is currently unavailable in Flow, so we can’t include both IsNew and IsChanged in the start element. (There is a way to replicate IsNew, but it is blocked when using IsChanged).
If you really need the solution to work on “create”, you can remove the start condition and add another Decision outcome. However, this flow will then fire every time a case is created or updated, which might potentially put a heavy burden on your system. Please evaluate carefully before you modify the solution.
3. It is a better solution than using Process Builder considering the performance
No matter you include “create” or not, you can still set the flow to run on a Before-trigger. This is always an advantage because Process Builder always runs on After-trigger (Always good to review the Order of Execution). However, if you already have a process controlling the Case object, you should consider building this solution into the existing process.
Does the solution solve your problem? If not, write us what your problem is and we will build the flow for you!