Keeping PCI out of our queue

Help
, , ,
1
  1. Bizness feeds us data in the form of XLSX files.
  2. Different processes drive off different pieces of data
  3. Some of this data qualifies as PCI under HIPAA, etc.
  4. Rules forbid storing PCI outside the network, so it cannot be put into a queue on a cloud Orchestrator tenant, (this happens to coincide with UiPath’s own recomendation regarding PCI and queues, which is: Don’t do it.)
  5. Rules considers encrypted PCI stored on an external server to be PCI stored on an external service so, aside from overhead and the need to manage keys etc., this makes encryption a non-starter.
  6. We’ve been PoCing an approach for last few days using an intermediating SQL Sever database: load data from spreadsheet into SQL Server database, generating a unique ID for each record, and then storing that ID in the queue.
  7. At runtime, robot uses that ID to query database for that record, gets and uses the PCI. PCI is never stored on Orchestrator, never leaves the confines of the internal network.

So, this works. But now we’re looking at the other end: reconciling the queue item with the associated data, to wit:

  1. User logs into O and checks status of their Q. Finds a non-zero number of exceptions.
  2. User views details of failed Q item. Business rule exceptions are the particular concern here because these need to be referred to somebody for manual processing.
  3. But all users sees is a seemingly random number… the unique ID assigned by the database… which means nothing. Meaning is only derived by manually querying the database for the ID. Nobody wants to do this.

So we’re looking for something a little more user friendly, I’ve already had a few ideas shot down because they’re not ‘Orchestrator-centric enough’. Everybody loves Orchestrator and nobody wants to go back to sifting through spreadsheets looking for failed transactions. We’re just limited with what information we store in Orchestrator. So wondering what people might suggest. Short of using the API to build a custom queue manager that could talk to Orchestrator on the one hand and SQL Server on the other. Not that I wouldn’t find that interesting, it’s just not practical at the moment.

ddk

2

@rabbit_rebozo
Hey,

I don’t know how much sense it will make.

  1. So assuming a BE happens, you already have this data from SQL with a GUID as a pk.
  2. Now assuming that, this particular process will be done by a user manually, you can store this data in encrypted share drive as a password protected excel file and send password across email to user; Now this particular user have read access over this encrypted shared with password knows to user only. Access to be defined in AD.
1 Like