pulldata(@layer) queries working for some, not others, in organization

Jump to solution
03-31-2023 10:03 AM
Occasional Contributor

Hello all,

I have created a hybrid workflow for my company that allows us to use an office-based survey to massively lighten the load on our field teams when it comes to data collection. This is accomplished through the pulldata(@layer) function. Programmatically, the system works entirely as expected and is able to source the correct data for different asset classes as needed.

However, it appears that the only members of our AGOL Organization that can actually fully utilize this functionality are those with the 'Administrator' role type. I have checked and rechecked that the feature layer being queried with pulldata() is shared with all relevant folks, and in fact a call with Esri Tech Support yesterday produced no meaningful changes to any settings regarding my survey data, and I am now waiting for more nuanced answers from an internal team.

This morning, I have been on the phone with a handful of our field techs to experiment what changing their role types would do. These are all people whose user type is 'Standard' and whose roles are all the default 'User'. I tried changing them one by one to all other user roles, and consistently the only user role that can make use of the pulldata() functionality is Administrator. 

I don't understand why this is the case, and the Esri folks I have spoken with so far don't seem to either. Having an AGOL Org that is completely composed of Administrators seems to defeat the entire purpose of having any discretion in assigning user roles, and I have to believe there is a way to enable my field teams to use the system I have created.

Has anyone else had success in managing the permissions/privileges necessary to enable an average field worker to make use of pulldata(@layer) and pulldata(@json) calculations?

1 Solution

Accepted Solutions
Occasional Contributor III

One difference for admin role users is that they can have access to all feature layer fields, even ones that are not included in the hosted feature layer view that is used by a survey. So maybe double-check that the hosted feature layer view definition includes all necessary fields.

View solution in original post

5 Replies

Does your form have a web form, and if so, can you determine what kind of response is coming back from the pulldata call using your browser's dev tools?

If there isn't a web form, might want to pull out Fiddler or Wireshark.

0 Kudos
Occasional Contributor III

One difference for admin role users is that they can have access to all feature layer fields, even ones that are not included in the hosted feature layer view that is used by a survey. So maybe double-check that the hosted feature layer view definition includes all necessary fields.

Occasional Contributor

I'm pretty green when it comes to network traffic stuff, so to be honest with you I'm not sure how to tell if my form does have a webform! The form itself was made in Survey123 Connect and published through the same means, and then beyond that I haven't done much of anything with the form itself besides change the sharing level from my company's AGOL website...


0 Kudos
New Contributor III

Hi Matt, I am now running into this issue. My pulldata @ layer stuff works totally fine if I'm testing but my field workers can't get anything to pull in. Did you ever find a solution to this? Seems odd this isn't documented anywhere in esri documentation:(

0 Kudos
Occasional Contributor

Hey @AdriannaBarton, indeed I did get to the bottom of this....though I probably won't be able to explain it all in the correct technical terms! Nevertheless:

First, let me state that my specific use case was to use data submitted by one survey as the data pulled into another survey - thus, I don't know how much help I will be if you are trying to pulldata from some other type of ArGIS layer. Now...

I imagine that you are using the URL/sub-URL in your pulldata(@layer) syntax is the one going to a Hosted Feature Layer that you own - this was the case for me. For example, I was originally pulling data from a URL that looked like this: https://services7.arcgis.com/.../arcgis/rest/services/service_90ca4c23d45743d4890163a41b1bb791/FeatureServer ; the "..." is not standard (I changed that to keep the data at this link private). However, everything else there should look familiar to you, particularly the long string of characters that comes after "services/service_", as that is the AGOL feature service ID of the feature layer being queried here. For some reason that I can't explain, the data at this URL is only accessible to me, no matter how I finagled the permissions of the hosted feature layer.

What you'll want to do is navigate to https://survey123.arcgis.com/surveys/ and select the survey you are wanting to use as your pulldata target. In the green bar on the survey results landing page, click 'Collaborate' in the top middle-right, and choose "Share results", making sure that viewers can see all records in the survey AND that they can view and export data (these two buttons are at the bottom of the "Share results" page). Doing this will create a "_results" layer in your personal AGOL Content. Within this item's landing page, you'll be able to get a link to the results of your survey, which is what you'll need for pulldata(@layer) to work. It should look like this: https://services7.arcgis.com/.../arcgis/rest/services/survey123_3546a64294114c4eadc46fcd17b07b7d_results/FeatureServer ; note the "_results" there before the final /. If you have any specific tables (aka repeats) in your feature service that you would like to reference, you'll see those listed under the 'Tables' bit of the overall item information page - clicking each of these will take you to a sub-item page where you can get a link to that result table specifically. Those look very similar to the above link, with a small bit of syntax added on the end: https://services7.arcgis.com/.../arcgis/rest/services/survey123_3546a64294114c4eadc46fcd17b07b7d_results/FeatureServer/1 ; the number following the / at the end corresponds to each table as they are introduced to the form in your original XLS form.

Finally, I also created a custom User Role for my organization that is nearly identical to the stock Mobile Work user role, but with some additional access and export capacities. If you would like to mimic that, here is the list of privilieges that role has:

Role Privileges:

  • View organization members
  • Join organization groups
  • View groups shared with organization
  • Create, update, and delete content
  • Publish hosted feature layers
  • View content shared with organization
  • Receive content
  • Share content with groups
  • Share content with organization
  • Make groups visible to organization
  • Network Analysis
  • Spatial Analysis
  • GeoEnrichment
  • Feature report
  • Edit features
  • View all organization members
  • View all organization groups
  • View all organization content
  • Update organization content
  • Share member content with organization.

I'm not sure if both of these are required - I had created the user role before I discovered the _results layer path. I would try just doing the _results path first, and if that doesn't work, add in the custom role! 

Silver lining here is that if the actual pulldata function is working correctly for you, it is just a matter of permissions within your AGOL Organization to get it working for your survey users - you should not have to make any additional changes to your XLS form outside of addressing those pulldata URLs to a _results layer.

Don't hesitate to DM me if you need more assistance!

0 Kudos