Difference between revisions of "CRMSFA Activity Security"

From Opentaps Wiki
Jump to navigationJump to search
m (Protected "CRMSFA Activity Security": Sysop page [edit=sysop:move=sysop])
 
Line 5: Line 5:
 
# Users can also be given permission to update activities.  However, to update an activity, the user must also have permissions to make updates for all the things related to the activity.  For example, if an event is related to an account, the user must be able to update that account as well as be able to update activities in general.  The same is true for opportunities, cases, contacts, and so forth.   
 
# Users can also be given permission to update activities.  However, to update an activity, the user must also have permissions to make updates for all the things related to the activity.  For example, if an event is related to an account, the user must be able to update that account as well as be able to update activities in general.  The same is true for opportunities, cases, contacts, and so forth.   
 
# Any user can create a "Private" activity which could only be viewed by the participants of the activity, or by a user with activity security administrator privileges.  "Public" activities could be viewed by any users with permission to view activities.
 
# Any user can create a "Private" activity which could only be viewed by the participants of the activity, or by a user with activity security administrator privileges.  "Public" activities could be viewed by any users with permission to view activities.
 +
# The owner of the activity can assign it to another team members.  Alternatively, the activity superuser (usually the sales manager) can re-assign any activity.

Latest revision as of 22:07, 19 November 2007

The opentaps CRM/SFA system imposes the following security management system for activities such as events and tasks in the system:

  1. To use the Activities feature of CRMSFA, including the Calendar, the user must have a permission to use Activities.
  2. Users can then be given separate permissions to view activities.
  3. Users can also be given permission to update activities. However, to update an activity, the user must also have permissions to make updates for all the things related to the activity. For example, if an event is related to an account, the user must be able to update that account as well as be able to update activities in general. The same is true for opportunities, cases, contacts, and so forth.
  4. Any user can create a "Private" activity which could only be viewed by the participants of the activity, or by a user with activity security administrator privileges. "Public" activities could be viewed by any users with permission to view activities.
  5. The owner of the activity can assign it to another team members. Alternatively, the activity superuser (usually the sales manager) can re-assign any activity.