Any Tricks on how to avoid sharing the XLS with users when sharing the App?

[Anonymous]

I have built a decent app (input, browse and edit records) and need to launch it to a large audience at my company soon.  I recently found out that I cannot launch it to 'everyone at this company' without sharing the Excel back-end with 'everyone at this company'.  And worse, they will be emailed the link to the spreadsheet!  My leadership has stated emphatically that this is unacceptable, yet this app must launch by early next week.    Is there any way to trick this so I can avoid it? 

So far, my attempts to get around this:  I exported my XLS into a SP list, and was about to move to that for my app's backend, but just know that when I make that move, I'll break my app.  And I really don't want to do that.  I was thinking this may be a way around it, but frankly I'd rather rebuild the app on the SP list than break the one on XLS.  It might be less painful, yet still I'll be up all night this week doing it., and don't really have the time.   (It's not vanilla out of the box - I had to customize a lot.)  What are thoughts about this method, if no other better ideas?  Also if I do move to the SP backend and it just breaks all over the place, can I version back to the one linked to my XLS without breaking it completely?  

Thanks for your help - in a bit of a panic here.  Tired of how long this has taken when it looked so much easier in the class I took a few weeks ago. 

[mdevaney]

@Anonymous 
I would say its best not to use an Excel spreadsheet when sharing with the company.  If you use a SharePoint list instead you can restrict who has access to the data and use a few nifty techniques to hide it from view so people can't find it.

Also, if you have 5 people or more using the Excel sheet at the same time performance tends to degrade.

---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."

[Anonymous]

Thanks and I agree now, especially if there is no way to trick the system into not sending out emails or obvious access to the XLS for my end users.  As for SP, any guidance on how to move?  I did port my back end data from the XLS to a SP list, and it's there and fine, BUT now, I'm terrified to move the back-end data from my PowerApp from XLS to SP.  Any experience with doing that, and not breaking it terribly?  And if do break it, can I version back?  Thanks!!!

[mdevaney]

@Anonymous
I think you’ll have a very easy time if you can make the SharePoint datasource have exactly the same name as your Excel file. That way you can delete the Excel connector and substitute the SharePoint with no breakage. I do this all the time when moving a SharePoint app from development to production environments.

—-
Please Accept as Solution if this post answered your question so others may find it more quickly. If you found this post helpful consider giving it a Thumbs Up.

[Anonymous]

Okay, I will try it after a few meetings today and report back.  The SP list should be the exact same as it literally came from the XLS I use as the back-end.  I haven't updated it at all.  Thank you so much for your help! 

[mdevaney]

@Anonymous 

Yep just keep the datasource and column names the same.  I'm sure it will be fine.

[Anonymous]

I did this, but forgot to keep the Datasource name the same (I guess not realizing when I was naming the List in SP, that should have been the same as the table name in my XLS.  Anyway, I mostly got around fixing those errors, because they were obviously what I did wrong.  Now, I have another set of challenges.  Maybe with your experience with this, I hope you can help:

• Worst issue - May be related to second bullet below, but now the User field gets overwritten with the Title (a string) field upon submission of a new record, and I cannot figure out why.  I've looked and looked, and nowhere does it seem to pull that field instead of the User field contents.  
• Two fields (one that holds the User().FullName info, and one that holds info from a Dropdown from another SP table) had broken Maxlength controls.  I deleted the contents of those controls, for those two fields, and no longer get the errors. But why did they stop working, if they were fine with the XLS?  I see now that DataSourceInfo doesn't work with everything, but again, why did they break now?  
  • This is what I had to delete:  DataSourceInfo([@'MyDataSource'], DataSourceInfo.MaxLength, "UserName") (here, I have removed my actual field names for generic ones)
• The Search field now is no longer nearly as robust as it was with the Excel back-end - I can't search on more than 1-2 fields now on the Browse screen.  The app still works, as long as I only try 2 fields, but it has the little yellow warning symbol.  I guess this is okay, but is there any way around it?  I liked how robust the Search was before, so am sad to let that functionality go...  

Thank you so much for your help.  

[mdevaney]

@Anonymous 

Best approach here is going to be separating these issues out into to smaller threads. 

Suggest to close this thread any then create 3 new ones.   That way each problem can have its own troubleshooting space and not get confused.

---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."