SharePoint Foundations 2013 - Trigger Workflow with Workflow

To start, there are multiple ways to do this, however I am only going over the method I used.

To append to my previous post about turning on the ability for an incoming email to trigger a workflow, that same project required an additional step so that after the email triggered a workflow to create a new task on a separate SharePoint List it would also trigger a notification of the newly created task.
For a Visual:
This is how its working prior to this fix
Email In > 'New Item' workflow triggered > Workflow Creates New Item and fills in details within another SharePoint List > New item created on list, there is a workflow set to trigger on 'new item creation' however this was done as a Service Admin (normal operation) so do not trigger workflow | STOP
This is how its working after the fix
Email In > 'New Item' workflow triggered > Workflow Creates New Item and fills in details within another SharePoint List > 'New Item' workflow triggered > email notification sent that a new item has been added to the list.

Unfortunately by default the workflow (email to task) runs as an administrator after being published if created through typical methods. An administrator of that level will not however trigger a workflow so even though the workflow was creating a 'new item' and I already had a workflow that triggers on 'new item creation' it ignored the new item creation as it was done by a admin (the SharePoint admin, not the same as a page/site owner - has to do with the account used within the services of SharePoint for backend operations). The workflow needs to have the 'create new task' steps on the 'email in' workflow within a 'impersonation step' as opposed to a standard step. The only issue with this is an impersonation step takes the currently logged in users credentials and impersonates them. If you are in a situation where your user accounts have password change requirements or you do not want to make a web of numerous different user being attached to different workflows because different persons are administering workflows the below steps would be beneficial.

A way around this is to create a new domain account for 'workflow triggering'. This is suggested so that the account may be setup without password expiration constraints (not sure if this will become an issue once the password expires - i.e. will it render the workflow inoperable until the workflow is republished with proper credentials? etc.) and all workflows can be related to one account for simplicity of management. Now, the fun part is publishing as this user. There are a couple of options - 1. Login to a system as the user (simpler if you have a development system to login with specifically for development of this and other systems) or 2. Use a function of Windows where you can 'Run as' another user whichever application you choose. I will be going over the latter as the first is fairly straight forward.

Run Application as another user-
-I apologize for being a little tunnel visioned but I will only be going over a Windows 7 environment for this situation and if you are running another flavor (XP, Vista, 8, Servers, etc.) you may or may not be able to follow the same instructions but the proper methods for your version are just a search away on the net.

On Windows 7 I could not 'Run As another user' from a shortcut to the application, I had to go find the actual '.exe' file. you must hold Shift and right click the executable and then an option will become available to run as another user. Input the credentials of the 'workflow user' and voila! Once you have completed the process of updating the regular step to an impersonation step simply publishing or re-publishing (in the situation that you already updated and published prior to this) the workflow will update the 'Published By' and those are the credentials used when the workflow triggers. Now your workflow can successfully trigger another workflow if it meets all of the requirements (New item created, item updated, etc.).

Hope this helps.