DomoJesseK Domo Employee

@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?