THaving the ability to generate PDF documents from within Dynamic Forms and Dynamic Registration has always been a very powerful feature. In most cases you will have all that you need to create a great looking document right out of the box. However there are times where you need a bit more refinement before you get it just right for your SPEC. In this post I will outline some useful tips on how to get your Dynamic PDF exactly where you want it.

This is a illustration on how to integrate a Dynamic Forms instance with an OpenWebStudio module instance.

We have had a few clients that have recently been integrating Dynamic Login with Facebook, Twitter, and Linked In and these clients have faced a few issues getting everything to work… This can be difficult to debug because a lot of the functionality is happening behind the scenes. Review this blog post if you are integrating Dynamic Login with either Facebook, Twitter, or LinkedIn and are running into any problems.

If you’re in the business of creating web sites, you’ll want a way to quantify what you’re doing. That way when a client comes snooping around and asks what you’ve been doing for the past month, you can easily show them how you add value to their business. Among all the things that you can do to justify your existence, one of the best tactics you can employ is to sync their website up with a CRM (customer relationship management) system. This will allow you go aggregate anything from web forms to recorded phone calls in one centralized location. In this tutorial, we’ll be syncing Salesforce (a brand of CRM) with an existing website running on the DotNetNuke platform.

We have started using 37Signals applications and more and such as Basecamp and Highrise lately for our own CRM needs. Many of our module for DotNetNuke and SharePoint have already integrated with Highrise and Basecamp for a while (via the HTTP Post feature in components such as Dynamic Forms and Dynamic Registration etc…) Our components and integration has worked great for many of our clients so that each time a user registers or submits a form that information is then posted into the Highrise contacts, notes, cases, etc… For our needs though and because we were already working with their API for integration with a new iPAD App we have been working on, we begin to realize that there is a real need for a much more integrated importing and updating tool for Highrise contacts. I think the importing tool that they have is “ok” I guess (I would love to see a direct SQL Query option or even newer versions of Excel) but it gets the job done… for us the challenge though was that we found it limited to ever update from our existing systems, tables, and queries that are housed in-house and we would have to clear out our contacts and build a new import each time we needed to “Refresh” some of these properties and custom fields within Highrise. For example, we like to manage things such as sales counts, issues, and customer history for contacts within Highrise however our existing systems cannot directly update these into Highrise. Furthermore (and pretty frustrating for us) has been that for imports if the contact already exists that contact is skipped during the import (I think it would be much better if you could import contacts and it would only overwrite new custom fields or fields that are brought in on that specific import).

Over the last couple of years we have had customers run into problems from time to time if they are trying to use modules such as Dynamic User Directory or Interactive User Import/Export to import/showcase users within DotNetNuke and then they might have discovered that while using Dynamic Registration to register users, they were not always “linking” the Dynamic Registration fields to DotNetNuke Profile Property fields. In the future we might force each dynamic field to be mapped, or at the very lease make it a required field and have it be “very recommended” even, if one of the options is still not to map the field. Mapping each profile property is really the recommended approach… but, if you are running into problems because your site has been live and has important user information that has never been mapped, you might find this post useful.

I wanted to start the new year off with a very public THANK YOU to Mandeeps for creating such a great blog module (Live Blogs) and also for providing us with the quality and support for installing and implementing the module (including converting our previous blogs over from NukePress, how is that for service!).

Sometimes the “DEBUG INFO” which will appear as Purple within the event log isn’t setup to be displayed. In these cases you can run this SQL Script (you can also go to “Edit Log Settings within the module menu for the Event Log under Admin, Event Viewer and define this as well).