Comments
-
@RJTracy can you speak to the concept of rows-under-management?
-
Got it. Thanks for clarifying. You have a few options: * Single app/store to both capture and administer data. Under this model, you could use the `env.userId` property to determine if the current user is an app admin (either hardcode the admin user ID's [easier] or query them from a dataset in Domo [better]). You could…
-
Gotcha. I think I might have misunderstood the issue...your goal is to allow a user to enter data into a custom app, then potentially update that data, while you surface the current state of those records within a card/cards. Is that right? If so, this can all be done within a single app. Let me know if I'm tracking…
-
Assuming you were referring to publishing the app and testing locally... Hitting AppDb can only be done on your local machine through a proxy in your local dev environment. When I've developed apps that interface with AppDb, I found it easier to just test that interaction within Domo, after publishing the app. Otherwise,…
-
I usually create a separate dataset that has only the most commonly-used fields. For example, a dataset containing all 300+ cols related to a Salesforce activity, then, in the same dataflow that produces the larger set, a second output set containing only the 50 most popular cols. That's the one I generally join to via…
-
You're correct that the store is app-instance-specific. You can only read/modify docs from within the app that created them. However, if you're syncing the store to a dataset, you could access that set from another app. That being said, you should be able to both list and update docs within that app. Have you already…
-
Hi Martin, Do you need to separate the original data from the updated data?
