About Vaults, Companies, and Users

These schema requirements must be met for a person to successfully access the ENOVIA products. The system fulfills all these requirements automatically when a company or person is added using the Administration pages.

• A business object of type Company must be created and promoted to the Active state. If the company has business units, a Business Unit object should be created for each and promoted to Active. The Business Units are connected to the parent Company with the Division relationship.

If you use the ENOVIA application to create a person, it creates both the administrative and business object for that person.

• A person administrative object must be defined with default settings for privileges. The role assignments that affect a person's ability to log into and use ENOVIA products, and access various menus, tasks, or objects are described in the product's user's guide. You can assign the person to as many roles as needed. For example, if the person needs to create projects and is an employee of the host company, you should assign the person to the Project User and Project Lead roles.
• A business object of type Person must be created with the same name as the administrative object. To log in, the Person business object must be in the Active state.
• The Person business object must be connected to the Company business object with the Employee relationship. If the person is assigned to a business unit, the Person business object must also be connected to the Business Unit with the Business Unit Employee relationship.
• To edit profile information for the company, including adding locations and persons, the Person business object must also be connected to the Company business object with the Company Representative relationship and assigned the Organization Manager role. The system automatically assigns this role when a person is designated as a Company Representative.

Every company must have a primary vault and can be assigned one or more secondary vaults. Each person added to the company is then assigned a default vault, which must be either the company's primary vault or one of its secondary vaults.

When host company personnel add a company to Program Central, they must specify a primary vault for the company. They can choose any vault that has been added to the system. A company's primary vault is where the company object is created and, by default, where all the company's objects are created such as business units, locations, and persons. Once set, a company's primary vault cannot be changed.

The host company can assign one or more secondary vaults for a company. The host company can add additional secondary vaults at any time but cannot remove them from a company.

By default, searches are performed across all primary and secondary vaults for the user's company.

During most basic searches, users can choose to search in a specific company vault or in all company local vaults. (Advanced searches are always executed across all company vaults.) Narrowing a search to specific vaults speeds up the search but can lead to unexpected results if the user is not sure where objects are stored.

If users typically want to search in one vault or all local vaults, they can set a global preference by clicking Tools > Preferences on the global toolbar.

When the general search dialog opens, one of the vault options is selected by default. This default selection is based on the following criteria and observes the following precedence:

• Vault set in the person preference setting. The preference is stored as an administrative property, property_SearchDefaultVaults, on the person object. This property remains undefined until the user sets the default vault preference explicitly through the personal preference page.
• System property emxFramework.DefaultSearchVaults. The default value is:

  emxFramework.Search.DefaultVaultPreference = ALL_VAULTS

• No preferences. If there is no preference is set for the Person administrative object as well as no value set on the system property emxFramework.Search.DefaultVaultPreference, then the default vault option is "All."

The property for the adminstrative person object and in the emxSystem.properties file can take any of these values:

• ALL_VAULTS--All
• LOCAL_VAULTS--Local Vaults
• DEFAULT_VAULT--Default
• Symbolic name of the vault name--For example: vault_eServiceProduction. If the property value matches one of the vaults available in the list box, that vault will be selected in the vault field. The value can have one or more vaults separated by comma.

When the vault is specified as "All" (ALL_VAULTS), this logic is used to obtain the list of vaults.

• Primary Vault--The vault of the company object to which the logged-in person object is connected with the relationship "Employee."
• Secondary Vault--The list of vaults specified in the attribute Secondary Vaults on the company object to which the logged-in person object is connected with the Emploee relationship. The value can be a vault list with symbolic names separated by tilde ("~") and may have local or remote vault entries.
• Primary and Secondary Vaults of Collaboration Partners--The primary and secondary vaults as explained above for those Company objects that are connected to the person's company object with relationship "Collaboration Partner."

When the vault is specified as "Local Vault" (LOCAL_VAULTS), the following logic is used to obtain the list of vaults.

• Primary Vault--The vault of the company object to which the logged-in person object is connected with the relationship "Employee."
• Secondary Vault (Local)--The list of vaults specified in the attribute Secondary Vaults on the company object to which the logged-in person object is connected with the Employee relationship. The value can be a vault list with symbolic name separated by tilde ("~") and may have local or remote vault entries. Only the local vaults defined in this list will be used for searching.

When using these ENOVIA applications, the system usually supports many companies in addition to the host company. Your vaulting strategy depends on the usage expected for each type of company. A company can be a buyer company, supplier company, customer company, or a combination of these types.

People who have a Buyer role (including Customer roles in a private exchange) create many more objects than people assigned to Supplier roles only. Companies that only have employees assigned to Supplier roles create fewer objects than companies who have employees assigned to the Buyer or Customer roles. As such, several supplier companies can share a single vault. Companies with buyer employees should not share a vault with another company. In fact, a buyer company may create so many objects that they need more than one vault.

When ENOVIA Sourcing Central is used as a public exchange, companies are not designated as a supplier or buyer company. A company acts as a buyer, supplier, or both simply by assigning the appropriate roles to employees and having the employees use the features associated with those roles. For example, a company might initially act only as a supplier company and have employees assigned only to Supplier roles. If that company decides to use pass-through RFQs, the company assigns some employees to the Buyer role and then the company becomes both a supplier and a buyer company. For private exchanges, companies must be designated as either customer or supplier companies.

ENOVIA Business Process Services installs these roles that can be assigned to users. You also need to assign roles based on the applications installed for your system.

The organization hierarchy is automatically mirrored as role hierarchy. When you create a Company, a trigger is fired that also creates a role for that Company.

Note: Company roles work differently from user roles; you do not assign company roles to users, and the company role does not show in the Roles category list for a person.

The Company type is the parent of Business Unit type and Department type. These types inherit the Create trigger and when one is created, a role for that type is also created. Because of trigger inheritance, all child objects of any of these types also have this functionality. However, if you create a custom create trigger for a child object, that trigger overrides the parent's trigger. To retain the automatic role creation functionality, the custom trigger must include the logic for creating the Company role. See Triggers for details.

If you modify the name of a Company, Business Unit, or Department, the name of the role is also modified to match.

The role hierarchy matches the Organization hierarchy defined for the Company when the objects are connected using the Division relationship. For example, if XYZ Corp has Business Units named East Coast and West Coast, then The XYZ Corp role is the parent to the East Coast and West Coast roles.

When a role is created based on a Company, the type admin property on that role is set to Organization.

The ENOVIA products have several methods for controlling access to objects.

You can assign accesses directly to a user, to a role, to a group, or to an association. These items can be used in policies and in custom JPOs to determine who can access what at which stage of a process. The user with that role/group/association has access to objects in specific lifecycle states as defined within the policy.

You can also use the Company Roles feature. See About Vaults, Companies, and Users. This feature creates a company role hierarchy that matches the company hierarchy. All users created within the company, or a child organization object automatically can be assigned the company role.

Some organizations may need to strictly control who can access objects. For example, Design Engineers should have access to specifications for their projects, but not for other projects. You can define a security scheme where a user must have the correct Project, Organization, and Role before access to an object is granted. This security structure is used by VPLM, but can also be used by implementing custom JPOs. To implement this structure, the Project and Organization user categories are used. Each user is assigned a Project, Organization, and Role which combine to define the security context. If a user's security context matches the object's security context, then the user has access to that object. All 3 user categories must match for access to be granted. You use the Business application to create the required user categories.

The existing rules allow multiple Business Units and Departments to have the same name if they are in different companies. However, if you want to use the security context method, you must ensure that there are no duplicate Business Units or Departments. These object names must be unique across all companies.

To maintain the organization and user structure, the security context feature uses these triggers:

• TypeOrganizationCreateOverride
• RelationshipDivisionCreateAction
• RelationshipCompanyDepartmentCreateAction
• TypeOrganizationChangeNameAction

As installed, these triggers are disabled. You must enable them to activate this feature. See the Business Modeler Guide for details on implementing the security context feature.

ENOVIA Business Process Services uses person objects to grant accesses to workspace members.

• Workspace Member Grantor can grant read access to the Workspace object only for all Workspace members regardless of specified default accesses. This access lets the user create new discussions and view workspace information.
• Workspace Lead Grantor can grant accesses to the Workspace and folder objects only for all Workspace Leads.
• Workspace Access Grantor can grant accesses to all objects in the data structure in addition to the access that a Workspace Member Grantor grants. These accesses are automatically granted down the data structure to at least all underlying folder and content business objects. The Discussion and Route objects for content also get the accesses from higher-level objects if their owners have not removed any accesses.
• Route Delegation Grantor controls temporary granted accesses so that a user can perform delegated tasks. The delegated grantee gets the access to the routed objects and Route that the original task assignee has.

ENOVIA Business Process Services uses these terms to represent a group of access privileges.