11/26/2024 9:26:14 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss general administration topics for SalesLogix (including LAN & remote topics). View the code of conduct for posting guidelines.
|
|
|
|
Absolute Read-Only. Is it possible?
Posted: 08 Jun 09 2:09 PM
|
I have some Accounts that only the Accounting department should EVER use -- but I want some people in Sales to be able to look at it. I do NOT want people from Sales to add notes, schedule phone calls or activites, change addresses, change phone numbers, or be able to add ANYTHING to these accounts.
I THOUGHT Account ownership and teams would do this, but I can't get it to work right.
I made a team called "Accounting". I changed a couple accounts to have an Owner as that team ("Accounting"). Then I made the acct mgr the head manager of the "Accounting" team. When I left it like that, no one who was not a member of "Accounting" could even pull up the accounts.
So I added a person from Sales to the "Accounting" team and assigned that person "Read Only Default". Then I logged in as that person and could see the "Accounting" accounts and was prevented from modifying the phone numbers, names, and other fields, but I was able to change the address, add notes, add history, and do all the other things I do not WANT them to be able to do.
We have v 7.2 lan.
Is there a way to TOTALLY lock down an account from someone, but still give them the ability to view it? |
|
|
|
Re: Absolute Read-Only. Is it possible?
Posted: 30 Jun 09 3:37 AM
|
Did you verify that your Security Profiles were complete?
I have seen instances where the profiles need to be manually adjusted (older Databases).
|
|
|
|
Re: Absolute Read-Only. Is it possible?
Posted: 01 Jul 09 10:53 AM
|
As you have seen many of the one-to-many tables like history, activities, etc do not have field level secureity enabled. If you look at the security profiles you will see not every table is listed in there. Also, some areas , like calendaring, is controlled via the calendar security as well as by functional security in SLX.
Apparently SalesLogix assumes that if you have access to an account that some things should be left open. You could script locking down some of the areas but There are some areas you can not get to. |
|
|
|
Re: Absolute Read-Only. Is it possible?
Posted: 01 Jul 09 11:39 AM
|
| Apparently SalesLogix assumes that if you have access to an account that some things should be left open. You could script locking down some of the areas but There are some areas you can not get to. |
|
And I think that for most businesses this may be the correct assumption.
For example, I may want to protect Sensitive Data for my Contacts (e.g. Date of Birth, SSN, Credit Card Numbers - and no, I am not suggesting that you store SSN or CC numbers on SLX without an overall secure environment, just examples of sensitive data) from being accessible by the Sales Team, but I want it accessible for the Accounting team.
Or, there are certain records that I don't want anyone to modify (e.g. If dealing with Parent and Branches I may want the Parent records to be static).
That shouldn't preclude me from Adding Activities against that record or Company.
Now, that being said, there are a few other alternatives here:
If you are concerned with Activities and Calendar, explore Calendar Security and Function Security (but keep in mind that these are user driven options and you won't be able to control them on a per account basis).
Same goes for history, there are some controls to prevent Users to modify records created by other users, but you are allowed to modify the records you create.
And finally, if you are looking into preventing Users from having visibility into certain Activities and/or History records, you could always explore adding a field called SECCODEID to these tables and then assigining ownership (again, doesn't prevent someone from adding, but may prevent users from having access to data that you deemed shouldn't be accessible even if you have access to the Main record).
* As a disclaimer, I have only Added SECCODEID columns to custom tables, so not sure how the system would behave if those are added to the these tables. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|