Skip to main content

We have recently purchased a K2 forms solution and are looking at ways in which we can allow business users to create their own forms without the ability to "break" anything. Has anyone given their business users this type of access and how does it work at a high level?

Hi Jrw252


 


You have 2 options here:


 


1)      Offsite users  use a VPN connection to the domain, or


2)      Expose a Runtime web-application in an external facing website


 


#1 will be the easiest to set up and also the cheapest. #2 will require an additional runtime license for SmartForms, as well as a public-facing IP address and host-header name.


Both options will require the user to buy a K2 Internet Connector license if the offsite users are not employed by the customer.


 


Kind Regards


Raymond


Hi'


 


No extra permissions are required for SmartForms to work. SmartForms uses K2 blackpearl permissions and rights with regards to
SmartObjects and Workflows.
However, rights can be set in IIS on the design time site level or on the runtime site level. The design time site and runtime site have
different web.config files and each site can be set up to use its own type of security mechanism. This enables administrators to allow
certain people to design SmartForms and other people to use SmartForms in runtime.
Follow the method mentioned above to set rights on the SmartForms sites. Alternatively, set the rights in the web.config files that can be
located in the following locations:
Designer: C:Program Files (x86)K2 blackpearlK2 smartforms DesignerWeb.config
Runtime: C:Program Files (x86)K2 blackpearlK2 smartforms RuntimeWeb.config


 


Please see the attached document.


 


Kind regards


Nelly


 


 


Just in case the OP's question isn't specific to SmartForms....

 

To publish a new process to the workflow server, users must have "admin" (and typically "export") rights on the server.  To publish changes to an existing process, users also need admin right son the process.  Unforetunately, these rights also give the users lots of power on the K2 server.  This is one of the reasons we have been reluctant to give other folks the ability to publish their own workflows.

 

That said, there are obviously some things you can do to work around this.  Probably the most common is to have "power users" who are creating workflows send their process to a publishing team using K2 deployment packages.  Then only the publishing team needs admin rights on the server.  With some effort, you can also automate this process such that a single service account has rights to publish to the server.  We have been able to accomplish this using TFS and MSBuild.


Reply