Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
18 replies
Subscribers
10 subscribers
Views
7148 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
Data and Records
Hi all, we are in middle of planning for complete moving data from apps to
natasav
over 9 years ago
Hi all,
we are in middle of planning for complete moving data from apps to tempo interface.
We had a several discussions of what is appian best practise for doing that.
Now wee have several question about records. On the system customer wants to keep all data permanently , so we suggest to do some king of archiving or saving necessary data in SQL database and displaying those data by using tempo report and tempo records in same manner as portal reports and process instance dashboard.
So my question is it possible to set security on record data per instance or entry level in same manner as process instance security? And if it's possible how can we do it?
And on the other hand how can we display a html data by using sail?
BR,Natasa
OriginalPostID-191793
OriginalPostID-191793
Discussion posts and replies are publicly visible
Parents
0
Chris
over 9 years ago
Sure thing. I know we did see performance gains (would have to re-test for an accurate measurement), but for us the reasoning was entirely scalability (performance is a nice bonus). Also to mention, the method of utilizing the 'IN' operator on a returned list of all processes a user has been a part of did not work for us either - reason being the 1 MB data limitation of query rules stops somewhere in the range of 22k IDs (would also have to verify the #). We need upwards of 50,000 for some users currently so this was another road block. Service backed records solved both this and the group method shortcomings.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
Chris
over 9 years ago
Sure thing. I know we did see performance gains (would have to re-test for an accurate measurement), but for us the reasoning was entirely scalability (performance is a nice bonus). Also to mention, the method of utilizing the 'IN' operator on a returned list of all processes a user has been a part of did not work for us either - reason being the 1 MB data limitation of query rules stops somewhere in the range of 22k IDs (would also have to verify the #). We need upwards of 50,000 for some users currently so this was another road block. Service backed records solved both this and the group method shortcomings.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data