DomoJesseK Contributor

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…