I am grateful to our many great partners! They are dedicated to helping companies replace manual paper processes with eforms, electronic workflows and data storage to automate & streamline their business.
One particular business provides healthcare and rehabilitation services. The CTO started an initiative to reduce paper and to improve their company from the inside out — enter “Barrier Busters”! Employees submit problems they see in the company (aka barriers) using an eform. The submissions are routed electronically to the management team for review and selection of the top barrier suggestion each month. Employees are excited because their suggestions are being heard and implemented and the company is seeing process improvements across the board.
109 barriers were submitted since April and 82 were busted! such as installing benches in the atrium to improve patient comfort. The nursing schedule has been made more user friendly with color coding. Blinds were hung in each of the exterior facing patient rooms on arch windows. And much more…
Kudos to Vebridge, a great frevvo implementation partner, for the work they are doing with this healthcare company.
They also converted their paper patient admissions forms to eforms and are excited to start using Live Forms’ new wet signature capture feature. And they have several other paper to eforms projects on their roadmap.
One of our partners asked this question the other day: “I had a customer demo and they asked me if form rules are server side JS or Client Side. I vaguely remember it to be Server side ? Is that correct? Are there any pro’s/con’s?”
The answer, as of now, is that they run server-side.
The main pros are:
- Browser independence. We found it impossible to get these to run reliably in so many versions of so many browsers, especially IE. A bug in your rule (e.g. an infinite loop) will crash the browser and in some cases will require a Windows reboot. On the server, these run in separate threads with lower priority and timeouts so it will not crash the frevvo server.
- The ability for the rule to do server-side things like http:get () to a database connector, invoke a REST service etc. These often reside behind the firewall and are not accessible to the browser.
- The rules are not exposed to the browser at all so any sensitive information in the rule (e.g. a password) won’t leave the server. However, we do not recommend putting any sensitive information in a rule.
- Rules can use information like the currently authenticated subject user id, name, email etc. though technically it would be possible to make this available on the browser if required. However, providing this information in the browser is a potential security hole.
- Rules can also modify a control – in theory, this can cause large-scale changes to the form’s valid state. Think of an optional XML complex type that has a deeply nested data structure inside it with some required and some optional elements. If any element has a value, all the other required elements become required. It’s much easier and efficient to analyze the form on the server although, technically, this is also possible in the browser. It can be extremely slow for large forms, especially in IE or if someone is running on a slower machine.
The main cons are:
- It makes offline use very difficult to implement. We are working on this. It’s not going to be in the next release (v5.1) but it is on the radar especially for tablets.
- Potential for performance bottlenecks. However, this is rare since rules are not compute intensive typically. We think the benefits outweigh the drawbacks here.
We’re working on a rule validator and a rule console to make it easier for customers to validate their script and easily view/fix any runtime errors while testing. More on this coming up.