I donāt know if anyone will have a fix for this, if I should post on github (because this is somewhat of a bug), or if someone has a hint for where I could start to work on the solution myself, but here is my issue:
I have a workflow that when a record is created, to create a task to update contact info. The Record is usually made in a subpanel in the Contact detail view (meaning it should be automatically related to the contact, and that works). The issue is that the TASK that workflow makes doesnāt get related to the contact, so the assigned user doesnāt know which contact to update. If the record is created via duplication (the record is duplicated, and then you edit it and save it) the task is related to the contact.
In short, when duplicating, the contact association is also duplicated, so by the time the workflow is triggered, the task is able to grab the appropriate relationship. If creating it from scratch, that contact association connects automatically (or manually, I tried also searching for the contact to relate the record to during but this problem persists) and that process of creating the relationship between the contact and the record takes time, fractions of seconds, but by that time, the workflow has been triggered, and the task created canāt get the proper relationship to the contact because the record itself hasnāt finalized that detail yet.
Iām sure I could add workflows to trigger it after the record has been created but the point is I shouldnāt have to. The workflows should be firing after a record is completely made, not halfway through. If someone has any advice on this itād be appreciated. Like I said when I started, post it on the github? Tell me where to look in the source files? It doesnāt quite matter I just think this is a general flaw in the timing of workflows based on new record creation that I have come across a few times and should be fixed.
Iāve been thinking about this and I am not sure it can be called a bug, even if it might be problematic in real life usage.
I think Workflows have to run when their specified trigger occurs, and so a task save will trigger the appropriate Workflows. The notion of āthe workflows should be firing after a record is completely made, not halfway throughā implies that a task is not fully created until it has relationships created around it, which I donāt think is very exact.
I would say that āduplicatingā is a composite process made of several parts (create record, create relationships, etc) and the way the Workflows are triggered in between is always going to be complicated.
The Workflow has no way of knowing if the record creation is part of a larger, composite processā¦ how long would it have to wait before running? What would it wait for?
Of course, I could be very wrong here, but this is the way I am seeing it now
So maybe you can consider customizing the duplication process, so that it is more aware of your case? Or perhaps work around this issue with some extra field signalling that the creation is over, and make the Workflow conditional so that it checks that field.
I would disagree on this slightly. Right now, if I make a task related to a contact, and have it create a record via workflow, the record isnāt related to the contact despite me telling it to be. That isnāt expected functionality.
Itād be like an assembly line where they make a a sandwich based on a menu. They get the bread right, ham, mayo, pickles, but before they realize there is supposed to be cheese someone else takes that sandwich and is told to ācopy it.ā The copy doesnāt get the cheese, and the original sandwich is finished, with cheese. Your customer would complain, because according to the menu, this sandwich is wrong. Theyād demand you remake the sandwich or want a refund.
I donāt disagree that workflows have to fire when the new record is created, my argument is that if I tell my task to be related to the contact, and tell the workflow to relate the record to whatever the task is related to, and the record isnāt related to that, then the workflow failed. It doesnāt matter why, although in this situation the why happens to be that the workflow fires before whatever query is done to obtain the contact_id for the task is being done (i guessing at the logic, but thatās probably the general process).
A. Record duplicated, gets saved
---- triggers āon saveā workflow
---- tries to use a related Contact, but none exists
B. Relationship to Contact created
What youāre asking for is this:
Record duplicated, gets saved
Relationship to Contact created
---- triggers āon saveā workflow on the first record
---- tries to use a related Contact, and succeeds
Now, I really do think this is impossible to achieve without some explicit coding from the outside procedure (the duplication), because there is no way to consistently or logically delay āon saveā Workflows triggering in general. What would it wait for? How long? What if that second event never happens? What if people need the opposite behavior, they might have a case where the Workflow needs to run before the relationship creation?
The best you could have is some way of signaling to the workflow that you want a composite transaction, that you need it to be delayed.
So the improved duplication code could run something like this:
create the new record, signaling āno workflows pleaseā
create the relationship
now force the workflow to run by re-saving the first record and allowing the workflow to run
I am not sure how this can be done, but I think that architecturally it would have to be something along these linesā¦
current functionality:
1.Create record via subpanel in contact detail view
2.āOn saveā is triggered when record is saved
3. Task is created via workflow but isnāt related to contact.
4. Record that was created was related to contact.
If I duplicate the record I created and save THAT then it DOES WORK. I just want it to work when I just normally create a record.
All I want is:
1.Create a record via subpanel in contact detail view
2. Workflow creates a task for assigned to
3. Task is related to the contact the record was related to.
My point is that for some reason, if I duplicate the record that literally didnāt work when originally, and save the duplicate, it does work, which leads me to believe there is some delay in the fetching the contact id part. This has also manifested itself when using a workflow triggered via lead conversion. I donāt want to duplicate my records. I was just merely pointing out that it isnāt the workflow logic that is causing this not to work, it is some sort of timing issue,
Ok, I hadnāt understood the part of the duplication being just a test, but the main point of my logic (unfortunately) still holdsā¦
Current functionality when creating:
A. Record created, gets saved
---- triggers āon saveā workflow
---- tries to use a related Contact, but none exists
B. Relationship to Contact created
The order of those things is determined by the code driving the ācreate-from-subpanelā functionality, and the structure of the Workflows architecture (where āon saveā means āimmediately on saveā, and thatās really the only way it can be).
Things change when you duplicate, in that case the new record is created with the relationship already there, and so the workflow can access it and create the task correctly.
You really need some custom code to work around this. It might be as simple as storing the Contact id in a separate auxiliary field, and filling this inside a before_save hook. Then the workflow could access it immediately when it needs to.
It just occurred to me that you might also have some luck if you try making your logic hook be triggered by the new relationship (after_relationship_add hook), instead of the new record. That way you might be able to do everything in one place, without auxiliary fields.
Sorry, I donāt think thatās possible. Or, in other words, āon saveā is already an āafter saveā workflow.
What you guys are asking for is to make āsave-and-relateā an atomic transaction, which I say cannot possibly be made without intervention from the outside calling code, because inside the workflow you have no way of knowing if you should wait, what you should wait for, how long, etc.
So I might have found my issue, and while it doesnāt fix some WF functionality (Converting leads has a similar issue and thatās a built in functionality) I found something that might apply to people in the future (if this fix works, which Iām hopeful it will)
The record I am creating via Quick Create in the subpanel is from a User made module. It is basically a quote/order module (I know thereās a quote module but for our specific needs we needed our own)
Now I just looking into which file(s) I would need to make changes to in order to get the contact id before the save when I realized something: Whereas other modules have their own QuickCreate.php that overrides certain functionality of the default file in the include directory, User made modules only use the default file. Therefore, certain base values are preloaded before save (fields that all records share such as created by, modified by, etc.) but not fields that are only in some Modules (some modules arenāt related to a contact without changing relationship properties, some only have parent id fields and then need to specify the parent type, etc.)
Therefore Iām betting that if I simply create a QuickCreate.php file for my module, overriding the parent file in the include directory, and preload the contact field, Iām betting my workflow will work as intended. If this is the case, Pgr is definitely right: The Workflow is triggered at the correct time, but the creation of the record needs some fine tuning.
Iāll post confirmation if this does or doesnāt work once Iāve written my adjustments and tested to make sure this is indeed the cause, but Iām hoping this will help people in the future if their confused on how Workflow operates or why their Quick Create isnāt creating records before WF is triggered.
