We have all seen this legendary post about using the App Connector to do back-end workflows and fetch data in step.
But this does not work for passing “things” or database items and returning them. Bubble literally treats your own app as a separate app, so even the same database item won’t be recognozied.
The other method is to call your own app, but it seems ot take the “unique id” of the thing and work intermittently. Also, returning a “thing” from the back-end using its unique id as text you need to do “do a search for” on the front-end which is not secure.
So what is the best way to pass “things” from front-end to back-end and return data to be used in subsequent steps? @keith@Jici
A returned ID via App Connector or API Connecotr can be converted to a Bubble Thing using Do a search for Type:first item with a constraint on unique ID (unique ID from API response). For a list of things, use unique ID is in rather than equals.
If the data is restricted by privacy rules, all of your logic should be in the backend so you don’t run into that limitation. If you need the result of that as a Thing, then you can also logically move that workflow to the backend in its entirety.
My use case: I have a public form (accessible via shareable URL to anonymous users) where people place orders. When someone submits the form, I need to create an order in the database AND submit it to the correct Shopify store using that store’s API credentials.
The problem:
Page type is “Influencer Gift Form” (a database thing)
This form has a field from_shopify_shop (Company data type)
The Company has privacy rules requiring “Current user’s from-shopify-shops contains this Company” - everyone else DOES NOT have access to any fields (everyone else being this anonymous user submitting the order)
When an anonymous user submits the form, I pass the influencer-gift-form object to my backend API workflow
The backend can create the Order with the relationship to the Company, BUT cannot access Company's shopify_access_token or Company's shopify_store_url needed for the Shopify API call (because it inherits the privacy rules from the user that kicked it off on the front-end - anamynous user)
This happens even with “ignore privacy rules” checked on the backend workflow
“Work intermittently” - I’ve tried the passing things via their unique id thru API connector to your own app. Sometimes the backend can access the company data, sometimes it returns empty/null values for the same workflow
“Not secure” - If I return just the company ID as text and do a frontend search, then frontend users could potentially search for any company ID, bypassing privacy rules. This is a separate use case where i am “signing the user up” client side during OAuth. Same issue tho - returning the thing “a company” to the front-end and tehn resolving it vai do a search for.
The core issue is privacy rule inheritance from frontend to backend when passing “things” as parameters.
You’re right about the ID conversion approach, but there’s a privacy rule inheritance issue that is complicating it for me.
The problem: When an anonymous user triggers a workflow that calls a backend API workflow (think form submission), the backend inherits the frontend user’s privacy constraints - even with “ignore privacy rules” checked.
My scenario:
Anonymous user on public form (page is a “Thing” with relationships to protected data)
Frontend passes Thing to backend API workflow
Backend can create records with the relationship, BUT can’t traverse it to access protected fields for API calls (even with ignore privacy rules checked)
Backend runs in anonymous user context who has “everyone else” permissions (basically nothing)
How can Do a search for [Type] where Unique ID = [passed ID] in the backend actually bypass inherited privacy rules from frontend context?
Personnally, I would create the order and schedule a backend WF to process the Shopify part and update order or use API connector + Backend WF and return data from API if needed (but I don’t think this is needed for your case).
Ignore privacy rules should be applied correctly. Maybe your issue is somewhere else. I may forget something but if I remember, if you check it on frontend and backend (ignore privacy rules), I know that there was a bug before that if you check both, it could return false instead of true. @georgecollier I think reported this… but I guess it was fixed since this was reported.
Yes. Using Schedule Backend WF, you can set your backend WF to “accept” the order created client side to the backend WF (just set a parameters to “order” with type DB order)
