Latest Contributions by TylerBragg2

Peter Klingman‌, Thanks for the update!  I'll check this out and I'm sure I will learn a few things.  I wasn't aware of the "sleep" function in Integromat, so I'll have to look into that as well.  Awesome! Tyler ... View more

Peter Klingman‌, Thanks for the update about the "extractChanges" functionality.  I can say that I have already tried to use this option, and I think there may be some issues with it (or the issue is with me).  I couldn't get it to work consistently.   Specifically, I am using the feature level webhook to trigger a scenario in Integromat when a few feature is added to the feature layer (This particular feature layer is the "assignments" layer in one of our Workforce projects).  The Integromat scenario then sends a text message (email to text) to the field supervisor to make him aware of the new assignment in Workforce.  I want to include the address and priority level of the assignment in the message so he has an initial idea of the location and severity of the problem, which is why I need attribute information.  As I was creating this workflow, I initially set up the scenario to use the extract Changes functionality that you mention above, which returns the Status URL, which contains the Result URL json file.  I tested all my HTTP requests in Postman, and everything worked perfectly.  However, when running the scenario in Integromat, I kept receiving an error when it tried to open the Result URL json file after the webhook trigger.  I can't remember the exact wording of the error, but it basically said that the json file (Result URL) did not exist.  When I went back to review the error (just moments later), it worked just fine and opened it right up.  So I was thinking that there may be a time delay in the creation of the Result URL json file after the extractChanges is triggered, and before that file is actually generated my Integromat scenario has already tried to open it, causing the error.  I don't know if this is actually what was happening, but it was the only explanation I could come up with.  Is there a way to determine the amount of time it takes for AGOL to generate this Result URL json?  Maybe it was an issue with the way I had things set up though.   So as a workaround, instead of using the extractChanges function, once the new feature is created and the webhook is triggered, my scenario makes an HTTP POST request to the feature server, queries where CreationDate was in the last 2 minutes, then grabs the attributes from the feature returned in that query.  It's working, but not ideal, especially in an event where two assignments may be submitted back to back within 2 minutes of each other (not highly likely, as it takes a minute or two to enter all the appropriate information for the assignment).   I would have included screenshots of this issue, but I abandoned the idea when I discovered the workaround, and now I'd have to go back and set the whole thing up for using extractChanges to see what was happening again.  It would be nice to get this working, as I could then parse the Result URL json, grab the "globalID," then make an HTTP POST request back to the feature service and grab the attributes of the feature with that globalID (instead of looking for features created within the last 2 minutes).   Also, the link that you provided above regarding the 'Create Webhooks' API Documentation, as you stated, is more of the API reference information and doesn't actually direct you as to how to go about getting the feature level webhook setup for the feature layer.   Thanks for following up on this!   ... View more

Hi Peter Klingman‌,  Regarding attributes in the payload of the webhook - we use those attributes, in several different cases, to attribute automatic notifications.  For example, I recently set up feature level webhooks for one of our ArcGIS Workforce projects layers.  When a new assignment is created in the Workforce Project, it triggers a scenario in Integromat that sends a text to the Field Crew Supervisor with the address of the assignment and the priority level.  In order to get the address and priority level, I have to conduct an HTTP POST request to the feature service and look for the feature with the newest creation date, then extract the data.  It would be nice if the feature level webhook would at least pass along the GlobalId of the feature (based on the "changeTypes" parameter, which is, in my case, FeaturesCreated).  I think ideally though, it would be a great addition to the feature level webhooks functionality if there could be a code block added that customized the webhook to include attributes of the user's choice in the payload.  I can't complain though - I'm excited just to have the feature level webhook functionality at this point!    ... View more

Are you still having this issue, or have you resolved it yet?  I notice that it's been a few months since your original post.  I was going to ask what module you are using.  If you are using the HTTP module to make a request, for example, the token has to be listed in the URL inside the module itself, and I understand that the token will expire after a certain time.  I say that because it may not be an issue with your main "connection" to your AGOL account in Integromat, but in the individual module.   ... View more

I'm seeing the same password screen.  I've been told by my ESRI rep that they just released new functionality for webhooks with feature classes in AGOL but they have no documentation yet.  I'm trying to find some information to get me going with this, but keep coming up blank.   ... View more

April, thanks!  I'm glad you enjoyed my post! To have the ability to distinguish between addData and editData you only need to set up one webhook.  In the "Add a hook" window, you have the option to "check the box" for either addData, editData, or BOTH.  You simply choose both in order to have the option to select which action will trigger which branch of your scenario.   Once you do that, you can add in a router where you want to branch off.  My router comes right after the Watch Survey module.  Then you add filters to the connectors AFTER the router going to either branch.  You are going to filter by Event Type, which is included in the payload of your Watch Survey module, as shown below.  Event Type will either be equal to "editData" or "addData", depending on which branch the connector leads to.   ... View more

As we have moved forward with the implementation of this process, there was one additional need that I addressed, and I think it is worthy of documenting.  This particular modification is to the dashboard used by the staff to process the applications.  Specifically, it was identified that there is a need for staff to have the ability to take applications over the phone when a customer calls in.  Rather than having to direct the customer to the online application (especially in the event that the customer may not have internet access or feel comfortable filling out a form online), the staff often take information for the application over the phone and submit the form on behalf of the customer.  In an effort to streamline the workflow for the staff, our idea is to have the dashboard be a "one-stop-shop" for processing.  So in lieu of having the staff open a separate link to the survey to submit a new application, I embedded the "new submission" version of the survey into the dashboard.  This is actually the second version of the survey that is embedded - the first version of the survey form is the one on the left side of the screen and is the "edit" version of the survey.  This second version uses the URL of the original survey without being in edit mode.  Here's what it looks like: The edit version of the survey is linked to the list you see and is filtered so that when an item in the list is selected, the corresponding survey record is displayed.  This is described in more detail in the original post. I added the "new submission" version of the survey as a second tab where the map frame is located.  This allows the staff to toggle between the "Map" and "New Application Form" tabs.  This can be accomplished by adding a new "Embedded Content" item to the survey and using the survey URL with no additional tags. Below is the screenshot of the Embedded Content configuration screen: This modification allows the staff to submit new survey records AND edit survey records from the same dashboard without having to open up another browser tab.   ... View more

I should also document one other issue I resolved: I have it set up so that Integromat will send a confirmation email to the applicant when the survey is submitted.  I recently encountered an error that stopped the entire automation when a survey was submitted when no email address was provided (I didn't want to make this a required field in the even that someone doesn't have an email address, or just doesn't want to provide one.  The information isn't 100% necessary.).  To get around this, I added another router immediately before the confirmation email module.  I then set up a filter on the connector to identify if an email was provided.  Now if an email address is provided in the survey, it sends the confirmation email to the applicant.  If it is not provided, the router skips the confirmation email and sends the process to the next module.  It looks like this: And here is a screenshot of the entire process now.   You may notice that the chart is arranged a little differently than it was in the original post.  This is simply because I used the auto-align tool and let it arrange them as it saw fit.  This is also beneficial for checking to make sure that Integromat is interpreting the branches the way you intended them.   You may also notice that I added an additional email module at the end of the last 4 rows (after getting the images from the survey).  This is because I was asked if I could send a notification email to our business license clerk when a survey was submitted that indicated that the property was a rental.  So I added a filter to the connector at the end of each of the bottom 4 rows that looks for the presence of different property owner information.  If that information exists (in my survey, the existence of property ownership information would indicate that the property is a rental), an email containing the property owner information is drafted and sent to the business license clerk so that she can check our database to ensure that the landlord has obtained the proper licensing for their rental property.  If property owner information is not present, no email is sent to the business license clerk.  Here's a screen capture of the filter: And the email details: I think this covers pretty much everything.  I'll also include the revised blueprint, fixing the issues I encountered, with this post.  If there are any other issues discovered, I'll post them up so that they are documented for the reader's benefit. ... View more

Ok Ismael Chivite, I think I've found the problem with my other org member editing in the dashboard.  In the screenshot above of the URL parameter of the embedded survey form, I had used "&objectID = {objectid}", which was based on this article: https://community.esri.com/groups/survey123/blog/2019/05/24/survey123-tricks-of-the-trade-editing-records-in-a-web-form.  In that article, under the section entitled "Embedding an edit web form within Operations Dashboard for ArcGIS," it is explained to use the globalID URL parameter, but the animation provided shows using the objectId.  I used the objectid after watching the animation.  I just went back and changed from using the objectId to using globalId and it seems to be working now - the other org member seems to be able to edit the survey form and submit edits successfully.  So there is a bit of conflicting information in that article, primarily the animation.  Below is a screen capture of the revised URL paramter using globalId, which seems to be working.  I gather that the difference between the two is critical to functionality of the edit URL parameter, and is important to note. ... View more

Ismael Chivite‌ Thank you so much for responding, and for the tip.  What you explained is what I was trying to do from the start, but I see now that I was trying to grab my objectId from the wrong place.  That really makes it much easier!  The issue if I change things around is that I still need to pull attributes from the feature in order to name the file dynamically.  So I'll have to pull info from the feature service either way.  Would you agree?   Now the problem I'm having is with having another org member edit the survey in the dashboard.  I tried to have the person submit some updates this morning, and they are getting this error: I'm sure it has something to do with permissions, but I've looked though the settings in survey123, settings of the feature layer, and this user's org permissions and everything seems to be correct.  This user is a "Creator" with the role of Data Editor.  She is a member of the group for which this survey is shared.  Have you guys seen this error or do you have an idea of where I should look?  Is it a setting of the embedded survey in the dashboard itself? Below is a screenshot of the URL parameters included in the dashboard: I'll keep looking for the problem in the mean time.  Thanks for all the help! ... View more