SaaS | Applied Information Sciences Blog

Technology is advancing rapidly, and with its advance comes new and useful ways to complete everyday tasks. In this post I’d like to talk about some of the benefits of replacing the paper- or desktop-based ways of an employee whose job is performed primarily in the field. (Home health workers or field service technicians, for example.)

Quality custom software that’s designed to meet the specific needs of a business is easy to adapt and should have minimal adoption time and training costs. Workflows that are built according to an employee’s ideal task flow should encourage thorough service calls and better communication flow in all directions.

As an employee who may have to make several service trips per day, mobility is essential. Paper can be completely eliminated, pictures no longer lost or need to be transferred by media card, forms can be filled out by simply speaking into a microphone and tapping on some check boxes. Signatures can be captured easily just by swiping a finger on a screen, bar codes can be read and captured. The possibilities for becoming more productive are expanding each day. Read More…

Jack OConnell

Yesterday, Microsoft announced the general availability of its offering of Infrastructure as a Service (IaaS). They join an already-crowded market of IaaS providers, but this offering gives all companies the ability to offload workloads that have traditionally run in a company data center to the cloud. Welcome, Microsoft — the water is fine.

This announcement also represents a major chunk of Microsoft’s family of Azure offerings…and in my opinion, a stepping stone many companies simply must take in moving out of the traditional data center and into the cloud. The following diagram shows the stepping stones out of the traditional data center:

Peter N. Joyce

It should come as no surprise that Microsoft’s strategy for SharePoint 2013 is cloud-based, SaaS, Hosted Services or whatever you want to call it. Whatever the name, the outcome is that custom, server-side code is no longer the way to go in the SharePoint world. This brings into question the fate of one of the workhorses of SharePoint since 2003: the Event Receiver. Microsoft has done a great job of exposing web services and creating the Client Side Object Model to enable scripting, but that doesn’t work when your application needs to react to an event that occurs in SharePoint.

SharePoint workflow could provide some of that functionality, but there is an overhead cost to workflow. When architecting a SharePoint-based solution and the question “Workflow or Event Receiver?” comes up, I always prefer event receivers until it’s proven that the process needs a workflow. If all the process needs to do is fire off an e-mail or update a field in another list or database, then why incur the overhead of a workflow when an event receiver will do the job with minimal management and overhead? But that doesn’t work in an app for SharePoint or in a hosted environment that doesn’t allow custom code…or does it?

I’m guessing you can tell from the title of this post what the answer to that is — yes, with remote event receivers.