I have a requirement where a non-Appian user needs to access data in Appian system either through SAIL form or in any other way and provide his/her inputs against the each field of Appian data which I need to capture back into Appian system. I have studied about Embedded Interface but as per my understanding it also requires to enter Appian credentials for accessing the Embedded Interface. Can anyone suggest me the best approach for achieving this requirement. Thanks in Advance
The easiest solution is to make them an Appian user. The platform is designed for named users. You cannot show an Appian interface to an unauthenticated user (including embedded).
Communicating with non-Appian users can be done through email parsing (which is difficult to implement well) or you can design your own interfaces in a differently technology than Appian (but communicate with Appian using Appian Web APIs). Please check the Appian licencing agreement when doing these methods to ensure doing so is not a violation.
What's the use case for non-users to use appian?
That is not the best practice. Also appian doesnt suggest to proceed it in that way.
Like the others replying to this thread I don't see the benefit to having them not be Appian users, especially since if I understant licensing correctly there's no additional charge for the extra users.
I do however, see significant detriment to attempting to allow non-users access to Appian system and data. Appian is very secure against SQL injection and cross-site scripts and other attacks. Other interfaces might not be as secure, and adding another layer adds more ways for problems (not only hackers but most likely hackers) to get in.
How are you going to configure security on the system the users DO have access to and configure security on the Appian process models that system is going to connect to? If there's a problem with this thing you built, is the problem in the external interface, in the Appian, or in the connection? Can you afford supporting all 3? If you made them Appian users, you'd only need to support the one system and they'd already have only the correct permissions at no additional cost. Why wouldn't you make them Appian users?
The licensing model is a matter that should be discussed between the licensee and their account executive. It’s not accurate, in general, that there is “no additional charge for the extra users”.
We see sometimes that designs are geared towards “gaming” per users licensing.
As all Appian consultants would agree, a primary guiding principle of Appian application design is implementing correctly. Users notice when an application is intentionally built in a sub-optimal fashion for the purpose of license rationing. Without user satisfaction, achieving success with your application can be an uphill battle.
Thanks Steven for your suggestion. We would be discussing with client about possible approaches and would proceed accordingly. I think the approaches possible are one would be making them Appian user other by accessing data from Appian through web API and showing it in an interface designed outside Appian.
Hi Bhanu Voora,
Yes, there is a possible to do that by using email parsing, By using external email users call our appian process model by passing some fields. you can capture that field data using receive email node,
Thanks David and Robert for your response. As per my understanding the client has asked for this requirement as it is something related to cost per user accessing the Appian is being charged and so they want to limit the no. of Appian users.
Robert Shankin Use case is - As part of the application only one task need to be assigned to a group of managers who needs to review the data and provide their comments back.
As mentioned above, as it is the only task the managers work on, client doesn't want them to be Appian users and also as they are the managers at high level they don't want to put their efforts in logging into any system and were expecting to have a simple way to provide their comments in the task.
Does the client use Outlook, and do they have SSO enabled?
If so, this could be a good solution:
Thanks Robert Shankin for your suggestion. I guess this approach will fulfill the requirement provided Admin rights to Outlook. Could you please clarify my below points with respect to this Task Viewer Add-in
1) The task url which we are being shown in the mail would be a normal task built on SAIL or any additional things to be configured for making it Embedded Interface?
2) Does the user on whose Outlook the Add-in is configured could be a Non-Appian user?
3) What will be the Assignment of the task which we are sharing in mail
I couldn't find answers to these points in the documentation shared hence requesting for your help.Thanks in Advance.
Note: at this time, this functionality is limited to the versions listed in Appian's documentation.
To your questions:
1) no additional work.
2) The recipient needs to be an appian user.
3) Assign the task to the user.
This is why I bring in SSO. If these users are a small few high-level executives. You can go to the effort to set up their PC's with the necessary add-ins, and to verify SSO is working for them. Then the users don't need to goto Appian - they just complete the task in their inbox.
I agree to the rest of the posts if the users is going to access appian in regular basis then they should be on-boarded to Appian.
I have a solution for a specific scenario which i have not implemented just an idea similar to RPA not sure if it violates the licensing agreement you need to check with the Appian team.
Scenario:- User access appian only once(Ex- Customer On boarding where customer needs to certain task once and never use appian ever)
1. Have a pool of users and use the task report to identify if there are any existing task or free users
2. If a free user is found, just update the email with client email before assigning the task so that an auto email is triggered embed username and temp credentials
3. When the user completes the task reset the password and release it to use for the next user.
Discussion posts and replies are publicly visible
© 2020 Appian. All rights reserved.