About Deploy

Deploy is a built-for-purpose field data manager; it enables the consistent and accurate collection of data from surveys and installation efforts.

How Deploy Works

Deploy takes the ease and convienence of web forms and adds in the missing components to become a fully-featured management tool for field data.

All access to resources within Deploy require a user to login with a personal user account. New users can only create an account using an Enrollment Link.

Projects are the top-level organizational structures in Deploy. They are used to contain all the structures listed below.

Roles are sets of permissions for a Project. A user in Deploy becomes a Team Member in a Project via a Role. The permissions set in a Team Member's Role define what they are allowed to do within a Project.

Sites and Locations are built into the context of Deploy and all collected data about a site or location can be viewed in its page. Each location is parented to a single site.

Deploy uses Location Groups to arrange locations into logical classes like "IDFs" and "Wireless Access Points".

Stages of a project are separated into Tasks, and each Task can be defined to collect a series of fields and/or photos. Task progress can be viewed and summarized for each location in multiple places. Tasks get associated with Location Groups, so each Location within a Location Group will have the same Tasks assigned.

Task Fields are inputs in a form which are used to collect data. A Task can have multiple Task Fields (inputs) defined with different parameters. There are also different Task Field types like Text, Number, Select, etc.

Photo Policies can also be defined for a Task to allow photos to be attached. A Photo Policy can require photos be submitted before or after data is collected or at any time. A Photo Policy can also set a minimum number of photos to be submitted before a task is considered complete.

Events are log entries within a Project. Each time something in a Project is added, modified, or deleted, an Event is generated and is added to the Event Log. A Project's Event Log can be viewed on its Dashboard.

Origin

Collection of installation information can be quite challenging. When installation or survey teams of any size need to collect and combine information collected from installers in the field (ie: IDF name, number of switches, etc), they often start by leveraging familiar tools.

These tools can range from pre-formatted emails, templatized rich-text documents (ie: Microsoft Word), or even structured data formats like spreadsheets, but there are soon discovered problems with these types of data collection:

• Media (photo) capture
• Updating templates and inputs
• Maintaining data consistency
• Combining multiple sources
• End-user visibility
• Built-in context
• Cross-referencing related information

Spreadsheets can present inputs to fill out information, but they can't properly contain photos. It becomes difficult to update the spreadsheet template and send it out to a large team, and when each team member has their own copy of the spreadsheet, all that data needs to be manually combined.

The next best solution might be web forms like those from Jotform, Smartsheets, or Google Forms. Web forms work well for most of the requirements, they can:

• Capture media (photos)
• Make updating the template easy
• Enforce very consistent data
• Require no manual combining of sources

Where web forms fall short is in the last three requirements: End-user visibility, built-in context, and cross-referencing of related information.

End-user visibility

Web form services allow a user to submit all the data requested in the form, but they don't allow that same user to view what has already been submitted. This becomes problematic when trying to keep track of progress, or when a user wants to look back at previously submitted data for reference.

Built-in context

Submission of general web forms will always require repetitive or contextual information to be submitted alongside the truely interesting information. For example, a basic IDF survey form could look like the below:

A surveyor visiting IDFs within a single site would repetitively input the same information for the first three inputs in this form.

Cross-referencing related information

When installers visit the same location multiple times throughout the stages of a project (ie, survey, installation, QA), they submit a new web form during each visit. Information from each stage then has to be manually combined together to form a wholistic view of submitted data for a specific location.

---

Change Log