I have an on premises sql server. The sql server has all my business data and customer contact information. I would like to sync the sql server with a crm product that would allow me to send emails and letters based upon the data in the sql server. Does anyone have a good recommendation for a crm product that would work well with my sql server.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SQL server crm integration
- Thread starter Gusbenz
- Start date
Olaf Doschke
Programmer
Sorry, I don't know a CRM adapting to any database design, it's typically vice versa, even CRMs open for extensibility and offering an API will require you to use their database directly or indirectly.
Just think about how things are coded, perhaps over the top of your head, if you never programmed something. Use of databases means queries, no matter if hand crafted or generated, they depend on a certain table structure, names of tables and fields, types and relations, maybe even triggers. You can't just attach any database, even though it has all necessary essential info for a CRM.
And there's another reason nobody being sane can give you a recommendation for a CRM: You don't tell anything about the size of your company and database. With just a couple of customers some systems are perhaps good enough, but with a rising customer base, you may need more sophisticated features. That's not just a problem of scaling well with the number of customers.
This is not like asking for a good hard drive or choice of Intel vs AMD CPU. This decision is not a merely technical one, it's a business decision and only you know your needs, so you canÄt delegate the decision for a CRM to anyone else.
What you will need, if your own applications process customer data, too, is either a full migration to let the CRM take over that part of your application features, too, then do away with your customer related tables and application features. Or you have to establish a two-way ETL process from your database to a CRM system database or API to keep CRM data of a CRM system and your database in sync. For that to be possible you need a CRM that is open about it's data, but it's not that kind of openness to let itself be adaptable to any database, in the first place it means to allow connections to its database in the first place. A system you rather use in the cloud as a service will likely not offer direct CRM database access, but access via web services or a Restful API, which would need to be used to write and read data to it. That'll be a costy module just to adapt your own data and CRM system data, but it may be worth it.
So you missed a past decision to look for a CRM system first and adapt your own development to the way the CRM needs its data. It's also a reason for the success of ERP systems like SAP, if a company is bigger. ERP systems don't just cover one topic like a CRM or a PLM or a Shop system, they cover the whole business.
Bye, Olaf.
Just think about how things are coded, perhaps over the top of your head, if you never programmed something. Use of databases means queries, no matter if hand crafted or generated, they depend on a certain table structure, names of tables and fields, types and relations, maybe even triggers. You can't just attach any database, even though it has all necessary essential info for a CRM.
And there's another reason nobody being sane can give you a recommendation for a CRM: You don't tell anything about the size of your company and database. With just a couple of customers some systems are perhaps good enough, but with a rising customer base, you may need more sophisticated features. That's not just a problem of scaling well with the number of customers.
This is not like asking for a good hard drive or choice of Intel vs AMD CPU. This decision is not a merely technical one, it's a business decision and only you know your needs, so you canÄt delegate the decision for a CRM to anyone else.
What you will need, if your own applications process customer data, too, is either a full migration to let the CRM take over that part of your application features, too, then do away with your customer related tables and application features. Or you have to establish a two-way ETL process from your database to a CRM system database or API to keep CRM data of a CRM system and your database in sync. For that to be possible you need a CRM that is open about it's data, but it's not that kind of openness to let itself be adaptable to any database, in the first place it means to allow connections to its database in the first place. A system you rather use in the cloud as a service will likely not offer direct CRM database access, but access via web services or a Restful API, which would need to be used to write and read data to it. That'll be a costy module just to adapt your own data and CRM system data, but it may be worth it.
So you missed a past decision to look for a CRM system first and adapt your own development to the way the CRM needs its data. It's also a reason for the success of ERP systems like SAP, if a company is bigger. ERP systems don't just cover one topic like a CRM or a PLM or a Shop system, they cover the whole business.
Bye, Olaf.
- Thread starter
- #3
OLAF thank you for the long response. What i think i want is a live sync of my current on site sql server with a CRM product. I currently have a view setup in the SQL server that has most of my important data. Currently, i run mail merges based upon the information in the view set up in the SQL server. Is there a CRM product that i can easily use the information in the SQL view to automate many of my processes.
Olaf Doschke
Programmer
I am not the expert of CRM systems. "Only" of database software development in general. This way is not the way it works. You never dictate where and how a system stores its data. You have to provide it in the way it needs it. In the worst case, a CRM system does not have an open interface for mass data input, many systems work closed in themselves. Of course CRM manufacturers know customers also are part of shop system and commercial or other campaigns, but that does not mean they are open to whatever you feed them.
To get an idea how you might attach to a online CRM, take a look at the API of insightly: Or Salesforce: Or Sugar CRM:
They don't work with views, they provide API calls to add data to their own databases.
Bye, Olaf.
To get an idea how you might attach to a online CRM, take a look at the API of insightly: Or Salesforce: Or Sugar CRM:
They don't work with views, they provide API calls to add data to their own databases.
Bye, Olaf.
- Thread starter
- #6
Olaf Doschke
Programmer
Every CRM has it's own database, you can't point any software, also not MS, to use your specific database, you have to transfer data in one or another way.
Microsoft Dynamics, are you talking about that? If that isn't used for your software already, it would mean a new SQL Server database (or a couple) would be generated, if you were to use that CRM and that would then need to be fed with your customer data.
In the end the bridge of your software and a CRM always will be porting data over, if only customer name and mail address. The CRM will generate it's own customer ID and all you need to map this to your data then will be your own systems ID and the CRM system ID. It's not impossible to do and once that bridging is established it may be synced even almost live, so each time your own software adds a new customer, it will also be made known to the CRM. That's what an ETL (export, transform, load) process does, though this terminology mainly is used for puling together data from multiple systems to a data mart or data warehouse for BI analysis.
Any CRM will have its own database. You exepct this to act like a hardware, like an oven, in which you can put whatever food you want. Software doesn't work that way.
Bye, Olaf.
Microsoft Dynamics, are you talking about that? If that isn't used for your software already, it would mean a new SQL Server database (or a couple) would be generated, if you were to use that CRM and that would then need to be fed with your customer data.
In the end the bridge of your software and a CRM always will be porting data over, if only customer name and mail address. The CRM will generate it's own customer ID and all you need to map this to your data then will be your own systems ID and the CRM system ID. It's not impossible to do and once that bridging is established it may be synced even almost live, so each time your own software adds a new customer, it will also be made known to the CRM. That's what an ETL (export, transform, load) process does, though this terminology mainly is used for puling together data from multiple systems to a data mart or data warehouse for BI analysis.
Any CRM will have its own database. You exepct this to act like a hardware, like an oven, in which you can put whatever food you want. Software doesn't work that way.
Bye, Olaf.
Olaf Doschke
Programmer
I agree with Simi, this is one of the possible choices, as you started off with software custom made for you, continue in that direction.
It also isn't impossible to export just the essential customer info and transform and load it into a CRM for making use of the whole feature set of that CRM, it does not end in mail merging for sure.
But the most plausible solution is to extend your custom software. If you see that custom software as a failure, if you don't cooperate with the vendor or developer anymore, the extension will be hard, then it would be advisable to migrate to a wholesome system anyway, not only CRM.
You can't stick together modules like CRM and PLM from different vendors easily, this is not a lego system. Either you go for individual custom made application landscape or a wholesome software suite like MS Dynamics. You can't pick just the Dynamics CRM module and combine that with anything else. The moment you opt for SaaS cloud solutions your major cost factor is finding developers for interfacing such a module landscape. And you also opt for not storing all data in a central single database, those systems will all keep their data in their places, you even don't keep them in house anymore. Both a burden and a relief. Backup and security needs go to the SaaS provider, responsibility for data privacy stays with you, though.
If you only aim for mail merge, well, then do you r own mail merge, a CRM offers much much more. Actually it is normally the system leading to customers, making contacts to leads to customers to recurring customers...
Bye, Olaf.
It also isn't impossible to export just the essential customer info and transform and load it into a CRM for making use of the whole feature set of that CRM, it does not end in mail merging for sure.
But the most plausible solution is to extend your custom software. If you see that custom software as a failure, if you don't cooperate with the vendor or developer anymore, the extension will be hard, then it would be advisable to migrate to a wholesome system anyway, not only CRM.
You can't stick together modules like CRM and PLM from different vendors easily, this is not a lego system. Either you go for individual custom made application landscape or a wholesome software suite like MS Dynamics. You can't pick just the Dynamics CRM module and combine that with anything else. The moment you opt for SaaS cloud solutions your major cost factor is finding developers for interfacing such a module landscape. And you also opt for not storing all data in a central single database, those systems will all keep their data in their places, you even don't keep them in house anymore. Both a burden and a relief. Backup and security needs go to the SaaS provider, responsibility for data privacy stays with you, though.
If you only aim for mail merge, well, then do you r own mail merge, a CRM offers much much more. Actually it is normally the system leading to customers, making contacts to leads to customers to recurring customers...
Bye, Olaf.
- Status
Similar threads
- Question
