Any way for a document/object to be sent through the workflow ON CREATION?

How are the objects being created?  Yoi should see the workflow section down at the bottom of the metadata card.  Depending upon your vault config you could even perhaps pre-fill the workflow, if that makes sense.

At a minimum the option should be available, though.

In the picture below I've drawn a (crude) arrow to the two sets of hyphens that are used to set the workflow.  The top one selects the workflow, the bottom the state.

To expand on what Craig said, if the documents/objects in a certain class should always go through a specific workflow, you can select the default workflow in the class settings. You can also enforce the workflow so that users cannot change or remove it.

Hi guys, many thanks for your replies. Apologies for my delayed follow-up; I was on vacation and wasn't on my computer much :-D

Actually there is no problem with workflows, and I have set-up specific workflows as default for specific classes (e.g. a Leave Request has a default/set workflow "WF_Leave Request" - exactly as you have shown, Joonas).

Anyways, my real issue was, when a user creates a Leave Request (or say any other object), they generally (in 99% of cases) want to circulate it in the workflow right away. However, the way M-F is set-up is that once the document/object is created, then the user has to go back and find it and then circulate it.
Is there any way that there can be the option to also start circulating such a document/object in the workflow upon creation?
I envisage something like the attached picture. If I click "Create & Send" the document/object will be created and at the same time introduced into the first stage of the workflow. Therefore, I wouldn't have to go back to look for the document and then to send it, as the current practice is for workflow objects.

You could configure the workflow, perhaps, so that the "Create and Send" workflow state is also available in the state dropdown when creating the object.  It wouldn't be a separate button, but it would still default as above, but allow the user to click the state, show that they want to do it in one step, and then click "Create".

You could look at options to automatically trigger transition. If the next step is always the same, it could be as simple as checking the all required properties have been filled. If there are different options as next step you could perhaps create some logic to determine which transition is allowed in the given case. If on rare cases people do not want to send the object off right away you might add a property that can be used to hold the object back until released manually.

Would be nice If there was an option to show and select the newly created object.. Then the User could simply switch the state from the task area after creation..

Thank you!
Actually, this is a perfect solution. The workflows in question have only one option (Send to Line Manager) so the automatic state transition will work perfectly. The way our workflows were set up mean that once created the object was left in an initial state and then the user had retrieve it and then actively push it to the next state. This is acceptable for certain objects but for the Requests I mentioned, it never made sense and users seen the intervening step as unnecessary. Thanks!

Hi, 

Unfortunately I ran into a issue that prevents an automatic transition from the initial into the next stage of the workflow.

The default/initial state is "Ready to send to Line Manager" and it should move into "Pending Line Manager approval" once created. Even when I remove the associated automatic transitions from the initial state, I still get the message. 

Any ideas?

Thanks!

What does the cut "Assignmen..." does? why would it need to go back to Ready to Send to Line Manager?

Hi Radu,

That state is "Assignment not complete".
If a user submits a Leave Request and their named Line Manager does not respond to the assignment in 2 days, then the Request is automatically returned to the requesting user via this state. This can allow the requesting user to change the Line Manager in case their named Line Manager (who is set by default on the metadata card) is also unavailable (we are not utilising the substitute functions of M-Files in our organisation at this time)

In our testing vault I removed this state and the automatic state transitions as I thought this would solve the issue, but it did not.
However, in a simple test workflow it seems the automatic state transition from initial state to next state works without issues, so I guess my issue is something to do with the set-up of the Leave Request workflow.