The official advice I've been given is to use Azure Logic Apps and Azure Function Apps in conjunction with one another having the Logic App do orchestration and Function Apps provide your workflow functionality.
This video on channel9 talks about it in detail ...
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK3179
... The Issue I have found is that the Logic Apps engine is an orchestration engine and not extensible so to complete the solution I think the ultimate solution would be something like an Azure Logic App for the business process that calls a Function for each workflow that needs to be run.
I have built my own workflow engine that I am hosting inside an Azure function with no guidance from MS on the matter ... their best advice was "get a £50,000 / year contract with the Premier Field Engineers program to have them come in and build it with you".
In our case, our flows / business processes are defined by our clients so we can't just hard code anything about how the business logic runs (e.g. by writing a fixed block of code in a function) and by treating a Function like a workflow Activity (think WF here) you would be following MS best practice but we found that our flows were sufficiently complex that the cost of executing flows in that manner would cost us real money for each execution.
This is how I ended up coming to the conclusion about running an entire flow inside a function.
In your case you can execute WF flows from a function to achieve the same solution we have.
Where this all falls down is that MS guidance on functions says that they should be a fast short lived REST call to do a small piece of work (perfect fit for an activity), so there's no telling what might happen when we embed a whole flow execution in there at this point your outside of their support offering from what I can tell and essentially "on your own" unless you take that £50,000 a year contract.
My thinking is ... try it, test the limits, put those in your code to prevent the functions framework breaking.
In light of this I have proposed through the feedback community that MS make functions embedd-able in to a logic app directly removing the overhead and our need to implement a separate flow engine.
https://feedback.azure.com/forums/34192--general-feedback/suggestions/36979045-workflow-solution
... if this gets approved we could design business processes as logic apps that call flows which would be built as other logic apps to stack the complete solution entirely on MS infrastructure "out of the box" without us having to jump through behind the scenes loops to make all this stuff fit when logic apps can't do something.
