Best Practices for Implementing Web Portal.

This question is answered

Hi All,

    I'm tasked with creating a web portal (for higher education) that will allow students to work through the application process largely via the web. It needs to integrate with Microsoft Dynamics CRM - which will be the CRM software for recruitment. I'm evaluating the different options I have in this matter and was hoping folks could throw some additional light on the matter. Namely, I'm thinking:

  • That making Dynamics CRM a IFD (internet facing deployment) is a bad idea and hooking directly into the Dynamics CRM database would be a bad idea.
  • That thus it makes sense to have a separate database for the web portal that the web portal interacts with directly (and thus users/hackers) which then on the back-end uses web services to sync information between the two databases.
  • That rather than writing an interface for admissions counselors to use in the web portal that they'll work directly within the Dynamics CRM interface.
  • Unsure that the Customer Portal Accelerator will be useful to me since it seems to integrate with an IFD rather than using a separate database? Can anyone verify this?
  • Wondering if there are any good articles that would talk about the best ways to implement prospective student authentication?

       If you use StackOverflow, I've also posted a question here.

      Thanks in advance for sharing your thoughts. I'm open to alternative ideas. This seems the logical way to advance to me - but I figured I'd try garnering some feedback before I plodded down this road.

Respectfully,
Dave

Verified Answer
  • I am not at all sure why you think all these things are bad ideas - having a separate database will create massive issues with keeping the two systems in line.

    IFD is secure as long as it is set up correctly (or are you suggesting all the companies that provide hosted CRM are insecure?)

    Portal Accelarator reads and updates the Dynamics CRM database directly (using web services) - if you are on premise you do NOT have to set up IFD to use this as the portal can run on your DMZ and use your inward facing ports to read / update CRM and your internet facing ports for external access.

    Portal Accelerator probably is a good example of the sort of thing you need.

    I have done several projects like this - albeit not requiring authentication - so I will leave authentication for others to comment on (the Portal Accelerator does have examples of this though using Microsoft's authentication.

  • My thoughts line up with Andrew.  There are several providers that can do this.  The one that created the protal accelarator has an advanced version of the accelarator.  You can find them here www.adxstudio.com. I would advise against the seperate databases.  It can be done, but you will have at least 2 more layers to develop and support going forward.

    Ty East
All Replies
  • I am not at all sure why you think all these things are bad ideas - having a separate database will create massive issues with keeping the two systems in line.

    IFD is secure as long as it is set up correctly (or are you suggesting all the companies that provide hosted CRM are insecure?)

    Portal Accelarator reads and updates the Dynamics CRM database directly (using web services) - if you are on premise you do NOT have to set up IFD to use this as the portal can run on your DMZ and use your inward facing ports to read / update CRM and your internet facing ports for external access.

    Portal Accelerator probably is a good example of the sort of thing you need.

    I have done several projects like this - albeit not requiring authentication - so I will leave authentication for others to comment on (the Portal Accelerator does have examples of this though using Microsoft's authentication.

  • My thoughts line up with Andrew.  There are several providers that can do this.  The one that created the protal accelarator has an advanced version of the accelarator.  You can find them here www.adxstudio.com. I would advise against the seperate databases.  It can be done, but you will have at least 2 more layers to develop and support going forward.

    Ty East