I need to track field changes/last modified within a list. From my research I have had a few potential leads but it ends up in programming which I am complete noob at, or, creating a workflow within SPD which I am more comfortable doing. I figured the fastest way to track it is to export the entire list versioning history into Excel so I can manipulate the data from there for analysis.
Is exporting this the best way to track field changes, or creating a workflow? If so is there an workflow example I can work off?
Thank you,
Claude
-Rookie SharePoint End User
Related
The question here is: Am I on the right path (this is the first time I'm trying this), and if not, what would be smarter to try? If this is the right path, can you offer suggestions on how to do this best, because if this works, I am going to use it often on a lot of different tasks in this app.
I'm running a PowerApps Canvas app. As part of its program, I want it to be able to reference (read-only) a collection of data. That data is in ServiceNow, and my group is not permitted to access ServiceNow using the API.
During testing of the app, I just had it reference a SharePoint list (which I had filled with some dummy data), but I can re-code those lines as needed to pull from some other data source.
Because I am touching a few different systems here, I am not sure if this is the right way to go and I'm afraid I'll spend too long trying and find out that it would never have worked because of x. Thus my question.
This is what I think will work. Am I headed in the right direction?
Set up the scheduled report in ServiceNow. (Done!)
Program ServiceNow to email the Excel file output. Make sure it is
always the same title. (Done!)
Build a Power Automate flow to capture that email and save the
attached file to a location (OneDrive?) that can be accessed by the
app. If there is a file there already, delete it first.
Add the Excel file as a data source to the app, and start
referencing it as needed.
8-12 hours later, ServiceNow pushes out another scheduled data
drop, and the whole thing updates again.
In my perfect world, this system would work completely unattended.
Offhand, a glitch I can see is that ServiceNow generates an Excel file, but it's not a table, and PowerApps I think must ingest as a data source an Excel file that is a table. But (shrug) I might be wrong.
Am I thinking of this correctly? Is this the best avenue to follow?
What I want to do: Generate a report in Word based on unique data that I manually enter for different clients.
I collect at least 100 variables of data for different clients. I must write a report for each client that contains this information.
What I have tried in the past: I tried to streamline this process by using Excel to enter the data in select cells and run the Mail Merge function, which would then export the unique data into a templated Word document.
Problem: Unfortunately, this process is prone to error and has a tendency to crash my computer.
Question: Is there a way that I can successfully make this a seamless process?
Note: I do NOT have any programming knowledge whatsoever but I am here because I think a non-programming approach is simply not efficient. I am hoping I can reach a solution to this issue by teaching myself basic programming principles. Is this possible?
Yes - one way is to first add the Microsoft Office Word references in the VBA window. Then you can set up a word document with bookmarks. Then for each data you would like to insert:
Doc.Bookmarks("Bookmarknamehere").Select
App.Selection.TypeText "ClientDataHere"
You will have to define the word application and document variables and the above will work.
I create a weekly report on sales opportunities and am being asked to report on changes (e.g. change in deal size, new deals, closed deals), specifically looking at the biggest changes.
Any tips on how to accomplish this?
Create a new SalesChangeHistory entity that gets populated whenever a Sales Opportunity changes via a plugin. It could include flags that specify if the change was a change in size, brand new, or closed.
If you didn't want to develop new entities and plugins you could turn on auditing and create an SSRS report against the audit data. The data isn't in the best format but it's achievable! (just!)
Having said this the "best" solution would be as Daryl has suggested.
I need certain custom entity fields to calculate and display values based on operations on the data in the system.
For example an a booking system implementation with contacts and custom entity: tickets. There is a one-many relationship between contact and tickets.I would like to create a field that calculates and displays in the contact form:
frequent flyers: more than 10 tickets bought.
a field that displays yes or no based on whether a first class ticket has ever been purchased. Ticket ref would start with say, FCxxx
If this isn't possible perhaps someone could suggest an alt method for displaying this info?
This is possible and you have some ways to do that: Workflow or Plug-in.
If you make a lot of calculations i think the best way is doing a plug-in. You can register in post create event of tickets entity and there you can make all this calculations and update the custom fields of contact entity.
You can check some tutorials about developing a plug-in:
http://mscrmshop.blogspot.pt/2010/10/crm-2011-plugin-tutorial.html
http://msdn.microsoft.com/en-us/library/gg695782.aspx
http://crmconsultancy.wordpress.com/2010/10/25/plugins-in-crm-2011/
Specific information about registering a plug-in:
http://msdn.microsoft.com/en-us/library/hh237515.aspx
In SDK you can find more examples.
As far I'm aware, it's not possible to achieve without coding. So, if you're looking for a way to customize it by mousing, you might be just out of luck.
If you wish to display that information upon retrieval of the a customer, it's probably fastest to get it using JavaScript. You can add a custom script to onload event. However, that means that you'll have to write JavaScript so if you're not into coding you'll have problems.
If you do know how to code, perhaps creating a plugin with C# is the most preferred way (that's what I'd do at least). The advantage of that lies in extensibility, should you realize that you wish to perform more operations.
Also, if you wish to store the computed values, you'll have to go with a plugin. Otherwise, only GUI operations will perform the computations. If a program will enter/retrieve data in the background, you can't rely that the values will be computed, unless you listen to the messages of Retrieve, Create etc.
We have a SharePoint 2007 deployment which will have a substantially large document library. My client wants the ability to export this library to an Excel spreadsheet, but specifically wants the ability to divide the spreadsheet into several worksheets based on a specific field. Is this possible to accomplish in WSS 3.0, through the object model or otherwise?
There is a out-of-the-box Export to Spreadsheet, but it does not appear to support automated subdivision of the list items into separate worksheets. I do not know if Excel Services that come with MOSS are capable of it, but we do not have MOSS so we cannot consider it an option for now.
EDIT
It seems that by mentioning "out-of-the-box", I am implying that I'd prefer something quick and simple. Let's dispel that. I do a lot of heavy work in the object model. I only mentioned the Export to Spreadsheet because that's the only available method I know of off-hand, and its options are limitted. So I am comfortable with all manner of work level that can be suggested.
I should also note that keeping the list linked with the spreadsheet is undesired. We want to be able to download the spreadsheet as a reference. Because of the number of people who will be working on the list, it would be absolute chaos to try and synchronize all of the linked files. My client has agreed that it'll be easier to handle obsolete copies than to try some synchronized system.
The solution also needs to be deployable. So things which do not tailor to an individual site are best.
You won't be able to do this OOTB. You will have to write some code to iterate through the records of the list either using
The SharePoint OM - Better performance and richer API but has to run on a Web Front End
The web service - Can run on any machine
Then you can build up the Excel spreadsheet either by
Using the Excel object model (aka Automation) if this is a quick kludge running from a workstation - but excel wasn't designed to be used from an unattended server and/or high volume so you may also want to look at
A 3rd party component such as SpreadsheetGear to generate the Excel spreadsheet files.
A good bet is to quickly create views for your items (using filters as you want) mirroring your desired worksheets and then export those views into excel. Those views update with the list and you can manually grab new versions later. Still manual but OOTB and no excel hacking needed.
I posted this on SharePoint Overflow. One of the answers I received there was very useful, regarding the utility of the Open XML SDK. Thank you to those who answered... I looked over your suggestions. My client has decided to go through with this one on account that it does not cost money to implement (as Spreadsheet Gear or datapresentation's plugin would).