When using the embedded form for data collection I would like to enable the user to continue working on the same form (record) after logging out and back in again. I need some kind of search function or way for the user to find what record he/she was previously working on, because each form is complex and needs a lot of time to complete. Is this possible?
Hi there,
That is a great question. When dealing with complex forms that require significant time to complete, the ability to “save and return” is indeed a crucial part of a smooth user experience.
To help clarify why the current Web Embed works the way it does, it’s helpful to look at the design logic behind our two primary embedding options:
1. Standard Web Embeds (Database Query, Viewer, and Form)
Our standard web embed tools are designed for specific, streamlined tasks.
- For example, the Form Embed is built specifically for one-way data collection (creating a new record). Think of it as a survey-style interface: once the “Submit” button is pressed, the transaction is complete from the perspective of a visitor.
- Because this tool intended for simple data entry, they currently do not support retrieving or editing existing records by design.
- As for the Database Query and Viewer modes, they also do not support editing existing records.
2. The “Direct Embed” Alternative
If your users need the full Ragic experience—including searching for previous entries and continuing their work—the most effective approach is the “Raw embed” option. This essentially places the full Ragic interface into your website via an iframe. In this mode, users can log in and manage their records with the same tools they would have on the Ragic platform directly.
Design Philosophy: Respondent vs. Editor
The reason we maintain this distinction is rooted in how we categorize user needs:
- The Casual Respondent: Someone providing data once (like a feedback form). They benefit from a minimalist, distraction-free interface because they don’t need to see the rest of the database.
- The Active Editor (Collaborator): Someone managing complex data over time. We’ve found that for “complex forms” like yours, users often rely on the “Professional Toolkit” found in our standard interface—such as Data Filtering to find their records, Version History, and Action Buttons (for sending emails or updating values with predefined rules).
Looking Ahead
While our current “Database Form Mode” is focused on new data collection, we are always interested in how our users interact with these tools.
If you find that the Raw Embed (the full interface) isn’t quite the right fit for your specific use case, you are more than welcome to share more about your workflow requirements. While we cannot guarantee immediate changes, understanding your process helps our product team evaluate potential future enhancements to our embedding options.
We hope this provides some clarity on the current options available to you!
Thank you. This does not quite fit our requirements. We’re thinking about using the API and building something custom. I don’t know this stuff well enough, but I suppose the API calls will give us access to all functionality that the standard ragic admin gui has?
Hi Auden,
Thanks for following up — and you’re welcome! To your question: API access in Ragic doesn’t carry its own separate, universal permission set. Every API call authenticates as a specific identity, and that identity’s existing access rights determine what the call is allowed to do — the same permission logic that applies to any user working in the Ragic interface directly. So the API can reach exactly as much of your database as the identity behind it is permitted to, no more.
One clarification worth flagging on “all functionality” — the API covers data-level operations (creating/reading/updating/deleting records, etc.), scoped by whichever identity’s permissions you use. It doesn’t extend to design-mode actions like creating sheets, adding fields, or configuring approval flows — those remain GUI (Graphical User Interface)-only regardless of which identity or key you use.
Now, there are two ways to set up that identity:
- Using an existing user’s identity — generate an API key for a user from that user’s Personal Settings. Every API call made with that key acts exactly as that user would, carrying that user’s individual permissions.
- Creating a dedicated Service Account — this sets up a separate, license-free identity built specifically for automation. Instead of tying permissions to one person, you assign it to one or more user Groups, and it inherits the combined access rights of those groups. Full setup steps here: Service Account.
The practical difference: option 1 borrows a real teammate’s account and consumes one of your internal user licenses (Ragic recommends setting up a dedicated user for this rather than reusing someone’s personal login, to keep the audit trail clean). Option 2 gives you a standalone identity scoped only to what you assign it, without using up a license — generally the cleaner choice when the API access is meant to represent “the integration” itself rather than any one person.
Since this is new territory for you, we recommend getting started by researching the Ragic API developer guide. The guide on Finding the field id for a field is helpful as well, since you’ll need field IDs for nearly every write request.
One thing worth being upfront about: building and maintaining a custom integration like this is development work on your side — Ragic’s support team doesn’t write or build the integration for you. What we do provide is the technical documentation above, and if you hit a specific issue while building or testing (an unexpected API response, a permission error, and so on), reach out to support@ragic.com and our technical team can help point you toward what’s going on. If your team would rather bring in outside development help for the build itself, we’re also happy to connect you with one of our consulting partners who take on this kind of implementation work.
1 Like