Security access is based on security groups. You configure
security groups to provide narrow access or broad access to applications,
sites, and labor. You can also provide access to general ledger components,
approval limits and tolerances.
Sites
The security architecture is designed
to use sites as the first level of security for multisite implementations.
You might consider using the following strategies when implementing
security:
- If your implementation has only one site, then for each group,
use the option to authorize the group to access all sites.
- If your implementation has multiple sites, create groups to represent
each site, all sites, or a logical grouping of sites within a security
group. For example, you can create a security group for site 1, and
a security group for site 2 and site 3.
- Do not include any other privileges for the site groups.
- An independent security group has access rights and grants that
cannot be combined with the rights and grants from other groups. If
you select this option, you must grant that group access to at least
one site and one application. You grant access unless the group is
being used exclusively for system-level applications.
Applications, storerooms, labor, general ledger components,
limits and tolerance, and restrictions
The following strategies
apply to applications, storerooms, labor general ledger components,
limits and tolerance, and restrictions:
- You can create groups that reflect these privileges. For example,
if your company or facility has four storerooms, you can create separate
groups for each storeroom and a fifth group for all storerooms. You
can add those groups to the profile for a user, as appropriate.
- You can create functional groups that combine some of the privileges.
For example, you can create three different maintenance groups. Each
group would have different levels of privileges for any or all the
properties in the tabs in the Security Groups application. This strategy
is good for defining groups in a detailed manner. When you associate
one group with a user, the group encompasses all or many of the privileges
that you want the user to have.
Depending on how you want to implement security, you can
also create groups that use a mixture of these two approaches.
Additionally,
the following rules apply to when security privileges include access
to applications:
- When you have access to a system-level application, any changes
that you make in that application have a system-wide impact. For example,
if you have access to the Currency application and add EURO as a currency,
that currency is available for all organizations and sites.
- When you make a change in an organizational-level application,
the change applies to all sites in the organization. For example,
you are a user at site 1. You have access to the Chart of Accounts
application, and make a structural change to an account. The change
affects all sites within the organization to which site 1 belongs.
- Any changes that you make within a site-level application are
limited to that site.
- The level of the application controls the amount of data that
you can view. For example, site-level applications list data for specific
sites, and organizational-level applications list data for all sites
within an organization.