Something we should build? Something that's annoying you? Drop feedback here. We're paying attention.
676 members
Hi everyone, I have registered for workato hackathon in hyderabad, can someone guide me with the steps to be followed.
Hi everyone 🙂 New to this community, but coming in with a request I've been thinking about for a long time. It would be amazingly helpful in nearly every Workflow App I deliver to be able to better manipulate data tables within Workflow App Pages. I'm talking basic filter, sort, adjust visible columns. Maybe I am missing something? Does anyone have a workaround beyond using visibility controls? I know about dashboards, but they don't quite satisfy. Even they could be doing with this feature. Always keen to hear how other people use these features! Thank you, Jenna
Job Report - Ability to Include "Result Schema" from a Recipe Function When creating Recipe Functions I often find myself exiting the Function and returning one or more values to the calling Recipe (see first screengrab). This is very handy but it does create an issue when customising the Job Report for the Function. That's because when customising the Job Report you're expected to choose the output from a discrete step in the Recipe to show in the output (see second screengrab). But the precise step at which the Recipe Function will exit depends on the exact logic followed for that particular Job, Referencing the first screengrab, one job might exit via Step 6 but another via Step 7. Since my code often has multiple Return points it gets very messy trying to include all of them (and it's a bit incoherent) so I don't bother. And therefore I hardly every use the facility to customise the Job Report - and that's almost criminal! So my suggestion is that, when working with a Recipe that happens to be a Recipe Function, there would be an ability to select from the "Result Schema" defined for that Recipe when customising the Job Report (see third screengrab). That way, regardless of which logic path any particular job took, it would be possible to see the returned values (in this case "Result" and "Notes") from the Recipe Function. In fact, it seemed so obvious to me that this is how it should work that I struggled at first to understand what was going on and why the Job Report only had values populated for Result and Notes some of the time. I can't believe I'm the only one who would find this useful. (Or perhaps I'm missing/misunderstanding something...?).
In addition to the above suggestion: It would be great if the Job History pagination allowed users to enter a specific page number and navigate directly to it. For example, if I want to check Job page #500, currently I would have to click the Next button many times to reach that job. Instead, we could have a page number input, where I can enter 500 and directly navigate to Page 500 to view the jobs on that page. 🚀 This would make it much easier to quickly navigate to specific jobs when working with large-volume records and troubleshooting function calls. 🔍
Hi, For *loops* processing bulk records, it would be helpful to show the current processing progress, for example “ 🔄 Processing record 1,100 of 1,500.”* Currently, to know whether the records are being added successfully, we may need to check the destination application. Showing the record progress within the job would give us a quick idea of how far the loop has progressed and make it easier to monitor large-volume jobs.
Heads up that this channel is still very new! We love getting your ideas here, please share. And also please note that we haven't formalized our processes to surface these ideas to our product teams just yet. All coming soon 🙂
I have a Feature Request around the “Monitor… Retry” functionality in Workato… For every API call I make to an external system I am, of course, enclosing the call in a Monitor… Retry clause in my Recipes. For the most part this is working nicely (or at least seems to be – we’d only notice if there was either a code/data or transitory failure). It’s the later scenario (transitory failures) that we’ve encountered a few times in the Dev environments when connecting to the API of a SaaS product (HubSpot since you ask). Very rarely (but enough to make a note) we get a 404 error from the HubSpot sandbox. However, by the time the error message is brought to my attention (even a few mins later), re-running the job then always works. So this feels like a transitory failure of the HubSpot API which seems to last just a bit longer than the maximum retry values allowed by Workato (i.e. 3 attempts with 10 second intervals between retries). Obviously the question of the availability of the HubSpot API is one for their support team, but it does raise a question around what seems to me to be an unnecessary limitation of the current Monitor… Retry functionality in Workato. Previously I’ve worked with integration teams and we’ve coded our own bespoke solutions to handle API failures. With this experience in mind I was surprised to see a maximum number of retries of only 3? In addition, the Time Interval Between Retries is very simple and also very limited in scope – allowing a maximum of only 10 seconds between retries. So with Workato currently, if an API endpoint doesn't recover in 30 secs max you're out of luck. And that seems quite a short period. With systems I’ve been involved in building we’d typically have more than 3 retries and the time intervals would span a longer period (usually spanning several minutes if not longer). And often we’d specify non-linear waiting periods as the retry count increased - say 10 secs, then 30 secs, 2 mins, 5 mins, etc. The aim obviously is to give the target system time to recover from any transitory failure. I realise that the Monitor… Retry clause is generic and not just for API use. And I assume there might be issues with a Recipe pausing for a prolonged period of time. But I still would have thought it would be possible to enhance the Monitor… Retry functionality along similar lines to that which I’ve set out above? Although this suggestion is prompted by the specific scenario we’ve seen recently, it is a common one in integrations, so I’d have thought it would be of wide benefit to the Workato customer base? This post at least serves to kick off this Channel anyway 😀
