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.
