but if the user wants to see more information about a specific record,
then the aim is to launch our program and search to that specific
record, thusly displaying all the extra pertinent information in our
system..
hopefully this makes more sense ??
Ok...very good.
Sure, if the people writing that CRM system want to open a particular form
in ms-access, and send that form to a particular record, then automation is
a good choice in this case.....
So, in the above, we would assume that your application is running already.
And, that application should not be "stuck" in some model, or dialog prompt
form. At this point, you could then have the CRM developers write some code
that attached to the application, and passes some record id number to a
routine in the access appcation that would then open a form, or perhaps
moving a existing form to the correct record.
Note that above can be tricky, since what happens if the ms-access is opened
to a customer record already, and some required field is not yet filled
out...and then the CRM system tries to move the form to a new/different
record. So, some of these things will take some thought on your part.
However, without question, you might want to build a set of routines in a
public module that does a basic set of features that the developers of the
CRM system might need
eg: - a routine to accept a customer id of some type..and then open a form
in ms-access to display/edit that form
- a routine to save/close the current forms data..and move to another
record.
- a few routines to printout a particular report.
So, sure...you can sit down with the developers of the CRM system, and come
up with a set of commands (subs you define) that they can call/run from
their code...