Every organization has different policies, every team has different relationships, and every project has different requirements. With ProjectVillage™, your organization, not the application, dictates process.

ProjectVillage™ does not hard code workflow functionality or rely on a least common denominator approach in an attempt to satisfy all processes with one solution. Nor does it use simple "status" drop-down lists that provide no enforcement or accountability. Instead, the application runs on top of a powerful and customizable workflow engine that allows member companies to design and enforce process within and across organizational accounts.

ProjectVillage™ workflow begins by breaking work process into seven components: Paths, Steps, Actions, Roles, Occupants, Permissions and Destinations. The application then provides a module from which an organization can create their own components and assemble them into their own process networks.

From the Workflow Design module, any number of workflow Paths can be created and assigned to other modules such as RFIs, Submittals, Punch Lists, Time Cards, etc. Once a Path is assigned to a module, that Path enforces the creation, workflow and resolution of items in the module.

Any number of Paths can be created for a module allowing an organization to support a variety of processes for different projects or team relationships. Within each Path, Permissions can be used to enforce which users can create which items on which Path.
Within a Path, any number of Steps are created, named and, within them, any number of Roles, Occupants, Actions and Permissions are added. Finally, Destinations are used to connect Actions to Steps, ultimately enabling an organization to create any imaginable process network.

Because Permissions are a fundamental component of workflow, security becomes dynamic. Because of this, unlike conventional static permissions, ProjectVillage™ security is enforced in the context of business process.

While administrators and implementers may create and maintain workflow paths, end users are not expected to formulate policy or master the mechanics of workflow design. Instead, for any given user, workflow design simply determines first, security (whether or not that user can create, modify or send an item) and, second, routing (to whom, to what Step and under what Action the item can be sent after it is created and while it moves from Step to Step). 

The workflow send screen below shows the ultimate result of workflow design from the end user perspective. 

Combined with the Enterprise Community® model, workflow design becomes particularly powerful in that document-based processes can cross organizational boundaries online. This opens the door for a wide variety of online business activity such as pricing, payment, design collaboration, bidding and materials procurement to name a few. As documents travel from person to person and company to company online, their status is always available in real time, an audit trail is automatically compiled and approvals and requests are completed faster.

Furthermore, anyone involved in a project, regardless of their participation in workflow, can access the application at any time from anywhere, providing an exhaustive resource of up to the minute project information from multiple organizations that is not realistically achievable with paper-based processes or conventional extranet architectures.