Few Questions, Company Considering CRM Options

đź’¬ General Discussion
1

My Company is considering several different CRM’s, a couple executives are pushing Salesforce, but I am working on getting a solid SuiteCRM demo set up with good test data to change their minds. I currently have it installed on IIS 7.5 using a MS SQL database as the backend. MS-SQL is a business requirement for our CRM candidates and after fighting folder permissions I have it working. I understand there may be some performance tweaks needed for IIS and MS-SQL as it currently has about a 1 second delay on page loads. I also have SuiteCRM tied into our Active Directory for user auto-creation and login. If we move forward with SuiteCRM we will most likely bring in a contractor, that is more familiar with the product for installation and eventually staff a php programmer.

I have imported the majority of our accounts into the Accounts module as test data. I am working on mapping our ERP db table to SuiteCRM accounts table.

  1. Will it cause issues if we write a stored procedure(trigger) to populate the accounts table directly? This would be a one way population to avoid loops.

  2. We also would like to send data back to our ERP in a controlled manner. From what I am reading it would be best to use a before_save logic hook in the php to export the data to a flat file that we process?

  3. This is not a business requirement, but is it possible to create security groups in SuiteCRM and link them to our MS Active Directory Security groups? Or at least assign a user to a certain security group based off an LDAP group when they are first created using LDAP.

  4. We use territories to assign accounts instead of users and would like to set it up in a similar fashion in the CRM. We would be able to populate these assignments from our ERP, is this possible? I took a stab at it but it does not seem to work currently. In the User Module I created a territory_num_c field which I then changed in the database relationships table as shown below but I think I am missing something.
    accounts_assigned_user | Users | users_cstm | territory_num_c | Accounts | accounts | assigned_user_id | one-to-many

  5. Is the Edit function in the Roles - all or nothing? We would like to have 3 edit levels. Super-Admin, Manager, and User. Super-Admin could edit all data in an account field, Manager would be able to edit the majority of the data with a few items greyed out, and User would only be able to edit common data.

Thanks in advance for any insight or help you can provide.

2

Hi there, welcome.

I’ll do my best to answer your questions…

There is no problem in doing migrations by handling the database directly, as long as the data formats are respected. These aren’t especially challenging, normally it’s easy to get things right with some testing.

If you choose to write your procedure in PHP, you can use the Beans objects to run your migration. This gives you access at a higher conceptual level (objects). This is nice when you want to import records and then set relationships and assign security groups.

You can see an example of such a script here: https://gist.github.com/pgorod/3ce7868a290df0ef4f8c9de74f12a6cd

If it’s a hook, it runs for a single record at the moment it’s changed. But since you mention a flat file for processing, I wonder if you don’t prefer a different approach, like a script running at the end of the day/week/month to put together that entire file?

If your ERP makes some API available, then I would definitely do it from the hook, updating the ERP so it is always in sync.

This would have to be a simple custom integration. On user creation, use the hook to check LDAP, assign the group.

[quote]4) We use territories to assign accounts instead of users and would like to set it up in a similar fashion in the CRM. We would be able to populate these assignments from our ERP, is this possible? I took a stab at it but it does not seem to work currently. In the User Module I created a territory_num_c field which I then changed in the database relationships table as shown below but I think I am missing something.
accounts_assigned_user | Users | users_cstm | territory_num_c | Accounts | accounts | assigned_user_id | one-to-many[/quote]

I’m sorry but I don’t understand your requirement. Each SuiteCRM user would be responsible for a territory, and this would comprise a set of accounts?

Please check this example for a suggestion on how to set up 3-tier security:
https://docs.suitecrm.com/user/security-suite-groups/#_a_typical_hierarchy_setup

You can do what you need, but possibly not like you were thinking. You would have to separate the different kinds of information in different records. SuiteCRM doesn’t do field-level security (which is what you’re asking, if I understand correctly.). So you can either try to achieve the same, but with information spread out in linked records, or you would have to write some custom code.

Tell me if you need any more information.

Also, when you’re considering contracting, remember SalesAgility can help you out with the migration, the customizations, and maintenance. Make sure you check out SuiteAssured, and tell me if you want to be contacted privately for details and prices. Thanks.

1 Like
3

I’m sorry but I don’t understand your requirement. Each SuiteCRM user would be responsible for a territory, and this would comprise a set of accounts?

You are absolutely correct. The Salesman gets reassigned to a new territory it would delegate to the Accounts or if the Account was moved to a new territory it would be assigned to that territories Salesperson. I was making assumptions when I was editing the database record. I may be going about it completely wrong and that is something that needs to be done with a custom module.

Thank you for your help on those quest that answers a ton that I can relay to the team when we discuss. I will definitely look at SalesAgility when we get ready to start. If we go the SuiteCRM route it would most likely be the SuiteAssured or atleast at minumum a support plan if they are supported with MS-SQL as the backend.

4

The “assigned to” mechanism in SuiteCRM is a specific thing, and should be understood well and used as it is designed. I normally explain it by saying it’s a mechanism for responsibilization, to allow records to be assigned to one (and one only) person. So it’s very handy to “pass records around” in the company, while making sure you always know who to blame :S if gets stalled.

What you describe seems to me a better fit (in SuiteCRM terms) for Security Groups. Each territory is Security Group, you can assign this group to many Accounts (see the Mass assign option in the List view). And users also get assigned to that group.

About SuiteAssured and Support Plans, we do provide them for customers running MS SQL and IIS, don’t worry.

5

Thanks,

I will spend a bit of time playing with the roles and see if I can make that work for testing in conjunction with tiered security and get an idea of how it will work.

The biggest thing I see using the security groups and roles for this will be tying it to our ERP for when a territory change is made to the salesperson or account. Also I am not sure I will be able to give the VP or Division managers the flexibility to make that change on the CRM using a module without having admin access. I am guessing it will need to be custom coded but is probably possible.