dave_slusher
ServiceNow Employee
Options
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 08-27-2020 01:50 PM
These are the questions and answers from yesterday's FDIH office hours. To see the next occurrences, check the Community event.
Note: These questions are not verbatim but boiled down and summarized from verbal discussions.
Question #1 from Alex: Is there some query that can be done to identify uses of Connection and Credentials Aliases in Flows?
Answer: I thought that there must be some query that can be done, but apparently this is not a direct relationship with a Reference column on a table. According to the developers, this information is compiled and not directly accessible via query. My instinct was incorrect.
Question #2 from Alex: Integration to Microsoft AD, a few times out of one hundred the response never returns but just hangs. This requires the whole Flow to be aborted. Is there a way to timeout and retry?
Answer: Double check your sys_properties to make sure com.glide.hub.flow_api.default_execution_time is defined (in seconds). If absolutely necessary, you could wrap the call to the AD Action with another action you control, and invoke with your own timeout. Docs are available here.
The question is still pending some more input. If I get a better answer later, I’ll edit this post.
Question #3 from Gabor: Is there a way inside a Flow to use internal variables such as a loop counter?
Answer: As of Paris, no. We can guarantee this feature is on the roadmap but as always, can never promise delivery of any feature on any timetable. At this point in time, the best you can do would be to add a table that may even just contain a single Integer column on it, and use that for your “scratchpad” like variable.
Question #4 from Gabor: The learning courses say the best practice is to put Flows in a scoped application. When doing Service Catalog related Flows, we have no scope so is there a problem with putting them in global?
Answer: This is Dave’s opinion and not necessarily canonical pronouncements: Scopes can make management of development, access control and promotion of development to production easier. However, if you don’t have a scope I don’t see a need to create one for no other reason than to contain Flows. As long as you are willing to handle the update sets to move these around, if they have no obvious home and no compelling reason to be in a scope, put them in global and move forward. If they are logic associated with a scoped app, of course put them in there.
I am willing to be debated on this subject, but in your situation that’s how I would decided.
Question #5 from Gabor: Transitioning from Workflows to Flows, there are catalog related logic as such: after approvals, fulfillment requests are generated. The recipient has the ability to confirm or reject that each was completed to their satisfaction. If the task was unsatisfactory, it is regenerated and put back into the logic after the approval step. How best to handle this looping logic?
Answer: After some talking, Gabor more or less solved his own problem. He is considering breaking this into multiple Flows with different triggers, instead of one Catalog triggered Flow that manages everything from start to finish. The first Flow would conclude at the generation of the tasks. The next Flow would be on the fulfillment task table, triggered by close and would merely look to see if it was unsatisfactory. If so, it would use the existing closed task to clone and regenerate a new one, probably with some annotation and linkage back to the original. This is much cleaner than putting weird retry logic in a complicated Flow.
Dave’s only concern is making sure that future developers (including Gabor a few weeks from now) are able to tell that these Flows are part of a unit and are both required to make the logic work as desired. This can be in internal documentation, naming convention, in Flow annotations but something should make this obvious so that can correctly handle the set of these over time.
Question #6 from Gabor: What is the future timing of these sessions? How can we know?
Answer: Every two weeks, alternating at 1800 UTC like yesterday and 1100 UTC. The Community event allows only a single time for the next occurrence and in keeping with best practice, I am using one event and updating each time. However, I can go low tech and edit in the text of the description of the event future times, which is what I have done. The Zoom link and password are the same for all sessions in both times slots.