Two Companies Work On The Same Project

The basis for our Enterprise Community® model lies in the simple fact that users from ALL organizational accounts are available to the security and workflow modules of EACH organizational account. What this means is that, as an administrator of your organizational account, you can grant permissions to projects in your account to users from other accounts.

To illustrate this, assume all extranet applications consist of a number of organizational accounts. So imagine that you are from a company called Acme General Contractors and you sign up for an account on an extranet service called Popular Project Extranets (PPE). Now you, as the administrator can create users and projects within that account. Once the users and projects are created, you can then give those users varying permissions to each project. However, the only users that you can give permissions to are the ones that you created in your account. That is, when you go to the security module in the PPE interface, select a project (or module within a project) and choose, say, "assign access", the list of users that comes up only contains the users that were created in the Acme account.

Within PPE, ABC Subcontractors may also have an account. And the administrator for ABC has created users and projects within the ABC account. However, like you, when the ABC administrator passes out permissions he or she only has those users from the ABC account to choose from.

Now let's say that Acme hires ABC for a project. How will you and ABC share information on that project? Well, on PPE you will have to choose one or the other account to put the project in. If it is decided that the project will be put in Acme's account, then you will need to create users in your account for the ABC people involved (note that there are now two users in this system for these ABC people: one each in ABC and one each in Acme). ABC now has most of its projects in its account and one of its projects in Acme's account. Worse yet, ABC cannot use the application to store or process information on this new project that it doesn't want Acme to see.

If, however, both companies were using ProjectVillage™, you could create the project in your Acme account and the ABC administrator could also create the project in the ABC account. Then when you are passing out permissions to your project, you could grant some permissions to the users from ABC's account. Likewise, ABC could grant permissions to your users in the Acme account. Then all users continue logging in to their respective organizational accounts (using one username and password) and, when they go to this project, they will see all of their organization's information on that project as well those pieces of information on that project from the other organization for which they have been granted permissions by the other organization.

To put this in perspective then, if I am a subcontractor, I could log in to my account, go into any project and see the drawings from the architect (because they gave me the permissions to do so), the RFIs from the general contractor (because they gave me the permissions) and the time cards and purchase orders from my company. However, neither the general contractor or architect can see my time cards or purchase orders (because I did not give them the permissions to do so).

Similarly, as an owner, I could log into my account and view all of my projects, regardless of who the general contractor is for each project. Without the Enterprise Community® model, to do this, I would have to have a different username and password for every general contractor that I've hired, which fragments my company's information. Alternatively, I would have to require that every general contractor that works for me use my account which would fragment the information for each of those companies.