I have some big concerns with the new flows and especially the work around, that is being pushed by knack.
With flows shared builders cannot work on flows. This is a big problem for everyone that work on other people’s apps. Shared builders is what makes Knack so useful. Now your flagship release is useless to many apps.
My second issue is the “workaround” suggested by knack. I can be given someone’s app id and API key and create flows in my app. This is a huge security issue and not only that the person who owns the app won’t have access to the flows a shared builder creates. That doesn’t sound right.
What do others think about this. Is anyone else concerned or does anyone see this as acceptable. I know of quite a few other builders that only work on other people’s apps and this seems to me a serious issue with flows.
I was very excited by flows but it looks like I will not be able to build any for any of the apps I work with.
All of my client applications are shared with me, so at the time of release, flows are not something I will be able to use without the suggested workaround. However, I am not comfortable using my clients’ API credentials.
Another option would be to co-build the flow via a screen-share or remote session. This is not my preferred option, as building out Make scenarios often requires time and extensive testing.
Agree this kills the utility of flows. I have 3 clients and am a shared builder to all. This will preclude me using flows in their apps. The suggested workaround is an unacceptable security breach.
Yes especially some of the more complicated scenarios.
I can’t imagine the client wanting to spend the time on it if they are paying someone to do it for them. I guess we will have to continue using Make for now.
Yes it’s the “workaround” that concerns me. Will the flows created be accessible by the client.
What happens when they stop working with a developer and they need to change the API key for their app. Do all the flows stop working until the new key is updated in each flow? Then anywhere else you use the API key will need updating.
Who owns the flows that a developer creates in their own app?
As a customer of shared builders I would echo my concern here (having worked with both Carl and Craig&Amanda).
Having my shared builder work on Flows with me is critical to me being able to use this feature extensively in my app. Sharing my API code to a shared dev is a huge security concern and also does not allow me to own the flow anymore, nor does it let me edit the flow! What happens if I am in the middle of a mission critical operation and suddenly the flow needs to be stopped? If it’s in my builders knack account and they are not available, or asleep (we are 8hrs apart) then I am screwed.
Luckily I am dangerous enough in Knack to be able to create some flows on my own (hopefully), but this will severely limit our use of flows.
FWIW I think a better solution would be to house flows withing a Knack app, and allow you to access other knack apps via API. This would mitigate this issue, and I really don’t understand the benefit of easily connecting different apps. The whole point of a database is to have many different tables interact with each other.
Is it only during the test period or forever? I’m not going to test it with my customers‘ applications. Using my customers’ API Key and app Id is taking unnecessary risks. It’s a shame because it’s a feature I’ve been looking forward to.
Thanks for bringing up these concerns! I’ve shared your feedback with @JohnKaras, our Head of Product, and we’re taking your points seriously.
From recent deep dive sessions with a number of our users, it’s clear that the current limitation with Shared Builders not being able to access Flows is frustrating. We’re exploring several solutions and aim to roll out expanded access improvements by late Q4 or early Q1. Our priority has been centralizing Flows access across all Knack apps in an account, which is guiding us toward easier ways to give Shared Builders broader account access and specific permissions, such as specific app access, the ability to create new apps, and handling admin/billing tasks.
In the meantime, one workaround that was mentioned in the thread here that might help is using the App ID and API Key of the Knack app where you’re a Shared Builder, within your own Flows area in your own Knack account. This will allow you to leverage Flows without needing any extra access to data you don’t already have.
We also heard your concerns about API Key refreshes. For example, as @CSWinnall mentioned, if you choose to stop working with a developer and the API Key for their app has to be changed. If you have specific thoughts on how you’d like this refresh of API keys process to work, or examples of common use cases, we’d love to hear more details! This will help us refine the approach and ensure it meets your needs.
Ultimately, our goal is to centralize and streamline access for all Knack apps in an account, which should open the door to giving Shared Builders more control—like managing admin/billing aspects and creating new apps for their clients.
We’ll continue to keep you updated on progress, and we appreciate your patience while we work on these improvements!
Thanks for replying. That’s great about shared builder access in the future.
Could you tell us who owns the flows if we build the flows in a different account? i.e. if I create a flow in my app that accessed data in a different account will the owner of the app control the flow?
This again brings up security and not controlling all the flows that work on their app if they can’t turn off edit or pause the flow when the shared builder stops working with the client.
If I build a flow For a client I don’t want to “own” the flow I want the client to “own” it. i.e. make.com I can be a shared builder but the scenario belongs to the main account.
I appreciate this is new and it’s an exciting development. I just won’t be able to use it until shared builders can build a flow directly in a client’s app/account.
@CSWinnall If you create a Flow in your account using an API key and an App ID of a client’s app, only you can pause or edit the Flow from your account. If the client refreshes their API key, the Flow will stop running until you update it with the new key.
We’re actively working on a more seamless solution for this situation.
Can you not see this is a major security issue. I hate to pick at a new feature.
I really don’t think you should be pushing this work around. It’s not secure and it’s not controlled by the owner of the app.
Sorry to push this point but it really matters. I wish @JohnKaras would have just said no shared builder access for now but it’s coming down the line.
Maybe I’m too cynical.
I think flows will be great, and I am sure when shared builders has been sorted it will be great for everyone.
Hi @CSWinnall - Thank you for the quick feedback and iterations here. Les, my team, and I are taking your feedback to heart: We will focus on explaining “Shared Builder are not supported for Flows, for now” as our message. There is nothing that precludes a Shared Builder from leveraging the AppID and API Key to create an automation, but we will not focus on that in our explanations to customers / other partners.
No worries at all – you’re definitely not being an annoying customer! Your feedback is really important, and it’s helping us shape how we communicate these updates going forward.
As John mentioned, we’re working to ensure our messaging is clear around the current limitations of Shared Builders with Flows. Please don’t hesitate to reach out if you have more questions or thoughts down the line!
On a side Q!! sorry to break the thread but it’s relevant, is there a list of current flow integrations apps? Im building and wondering if I should wait or use Make/Zapier/N8N/Trigger
I’ve got Knack newsletter about the new flows available in October but I can’t find it in the Builder. Sorry for the silly question in the tread but I figured It would be quicker to get an answer here instead of contacting support Is it not available yet? I am anxious to start Quickbooks integration
